Ingeniería inversa de MCU

Parte 16 - Mostrando números en la pantalla LCD

En tutoriales anteriores, aprendimos a enviar cadenas de texto fijas y caracteres ASCII individuales a una pantalla LCD conectada a nuestro MCU ATmega32. Textos estáticos como "Bienvenido" funcionan para etiquetas simples, pero los proyectos embebidos reales casi siempre necesitan imprimir valores numéricos dinámicos capturados de sensores, temporizadores o contadores en tiempo de ejecución almacenados en SRAM y memoria EEPROM. Muchos desarrolladores novatos piensan inicialmente que pueden envolver números brutos entre comillas dobles y pasarlos directamente a Send_A_String, pero este truco solo se aplica a texto de dígitos estáticos, no a enteros variables o lecturas de punto flotante que se actualizan mientras el microcontrolador ejecuta. Aprender a convertir variables numéricas vivas en secuencias de caracteres imprimibles es una habilidad embebida fundamental, y este flujo de trabajo también es importante para la depuración de seguridad: podemos imprimir valores de fusibles en tiempo real, estado de lockbit y códigos de error de lectura de volcado flash en el LCD para detectar intentos de desbloqueo no autorizados antes de que los atacantes realicen la decapsulación y la extracción completa de firmware para la producción de dispositivos duplicados.

Al depurar la lógica de seguridad del MCU, a menudo necesitamos imprimir métricas numéricas críticas en coordenadas de pantalla fijas en lugar de dejar que el texto se desplace por todo el búfer LCD. Si actualizamos continuamente una lectura de sensor en la misma línea sin restablecer la posición del cursor, los dígitos antiguos se superpondrán con los nuevos valores y crearán una salida ilegible y confusa. Una función de posicionamiento de cursor dedicada resuelve este problema por completo, y podemos reutilizar esta misma lógica de control de coordenadas para colocar cadenas de advertencia que alerten a los usuarios sobre posibles riesgos de volcado o ingeniería inversa en la pantalla.

El valor de comando central 0x80 controla el posicionamiento del cursor LCD para todos los módulos de caracteres paralelos de 20x4. En representación binaria de 8 bits, 0x80 se traduce a 0b10000000; el bit único más alto actúa como una bandera que indica al controlador LCD que los siete bits inferiores restantes almacenan un desplazamiento de dirección de memoria de pantalla. Siete dígitos binarios pueden codificar valores decimales que van de 0 a 127, lo que le da al hardware LCD 128 ranuras de memoria únicas para almacenar datos de caracteres para cada línea de pantalla conectada. Este estándar de mapeo de memoria es universal en todos los chips IC de LCD de caracteres fabricados para la integración con microcontroladores.

El LCD de 20 columnas y 4 filas de nuestro tutorial solo usa 80 de las 128 posiciones de memoria totales disponibles, lo que deja suficiente espacio de direcciones no utilizado para paneles LCD industriales más grandes con filas y columnas adicionales. Cada pantalla de caracteres compatible sigue esta misma regla de diseño de memoria de 128 ranuras, por lo que el código de posicionamiento del cursor que escribimos para el MCU ATmega32 se transferirá sin problemas a otro hardware MCU sin un trabajo de reescritura importante. Esta compatibilidad cruzada también facilita que los hackers analicen el código de volcado flash en bruto durante la recuperación de código si no habilita la protección de bloqueo adecuada mediante fusibles programados.

Cuando llama a Send_A_Command(0x80), el cursor LCD salta a la primera ranura de caracteres en la esquina superior izquierda de la pantalla. Pasar 0x8A como comando desplaza el cursor diez posiciones a la derecha a lo largo de la primera fila de la pantalla. Un error común para principiantes implica malinterpretar cómo el espacio de direcciones de memoria se envuelve entre filas: incrementar el desplazamiento de memoria más allá de la columna 19 de la línea uno no mueve automáticamente el cursor a la línea dos. En cambio, el diseño de memoria divide el búfer de 128 ranuras uniformemente en dos segmentos de 64 direcciones. El primer segmento (0–63) sirve a la Línea 1 y la Línea 3, mientras que el segundo segmento (64–127) maneja la Línea 2 y la Línea 4. Esta división fija estándar garantiza un comportamiento consistente del cursor en pantallas LCD de dos líneas pequeñas de 16x2 y pantallas industriales grandes de varias filas por igual.

Esta regla de partición de memoria garantiza una lógica de programación uniforme independientemente de las dimensiones del LCD. Incluso una pantalla teórica de dos líneas con 64 columnas completas ocuparía completamente cada segmento de memoria sin romper la lógica de cálculo de coordenadas. Los aficionados y los ingenieros embebidos comerciales pueden reutilizar la misma lógica de cursor al cambiar de hardware de pantalla, lo que reduce el código redundante almacenado en la memoria flash del MCU y reduce el volumen de datos capturados durante operaciones de lectura de volcado no autorizadas.

Calcular manualmente los valores de desplazamiento de memoria en bruto cada vez que desea mover el cursor pierde tiempo de desarrollo e introduce errores de cálculo humanos. Podemos abstraer toda la aritmética de direcciones en una función reutilizable GotoMrLCDsLocation que acepta entradas de coordenadas X (columna) e Y (fila) simples, como GotoLocation(6, 4) para posicionar el texto seis columnas a la derecha en la cuarta fila de la pantalla. Sin esta rutina auxiliar, los desarrolladores necesitarían calcular manualmente desplazamientos como 90 para el sexto carácter de la cuarta línea, donde 64 marca el inicio de las líneas dos/cuatro, sumando 20 por cada fila completa y seis columnas adicionales para alcanzar la posición objetivo.

Para construir esta función de posicionamiento basada en coordenadas, primero creamos una matriz que almacena el desplazamiento de memoria inicial para cada fila de la pantalla en nuestro LCD de 20x4. Cada entrada dentro de la matriz de caracteres firstColumnPositionsForMrLCD contiene el valor de dirección base para la Línea 1, Línea 2, Línea 3 y Línea 4 respectivamente. Seleccionamos el tipo de datos char porque todos los valores de desplazamiento se ajustan al rango numérico de 0–127 admitido por una variable de carácter de 8 bits con signo, minimizando el consumo de memoria RAM en hardware MCU con recursos limitados.

El nombre de variable largo sigue las mejores prácticas de codificación embebida estandarizadas para eliminar ambigüedades y prevenir conflictos de nombres de variables accidentales en proyectos de bibliotecas de múltiples archivos. Cuando dividimos nuestra lógica LCD en archivos de biblioteca .h y .c separados más adelante en la Parte 17, esta etiqueta de matriz descriptiva evitará colisiones de nombres con otras variables globales que manejan coordenadas de registros de volcado EEPROM o valores de seguimiento numérico lockbit.

Podemos optimizar aún más la definición de la matriz con una macro #define para el número de columnas, lo que permite a los desarrolladores ajustar el valor una vez para que coincida con diferentes anchos de LCD en lugar de reescribir cada número de desplazamiento dentro de la matriz:

Esta configuración impulsada por macros simplifica la migración de hardware cuando intercambia una pantalla de 20x4 por una pantalla de 16x2 durante revisiones de prototipos, y reduce la cantidad de literales numéricos codificados visibles dentro del código extraído por volcado durante el análisis de ingeniería inversa.

La función completa GotoMrLCDsLocation combina el desplazamiento base de fila obtenido de la matriz con el valor de columna objetivo, más el bit de bandera de dirección de memoria 0x80 obligatorio requerido por el hardware del controlador LCD:

Las operaciones de resta (y-1 y x-1) existen puramente para una sintaxis de entrada fácil de usar, permitiendo a los desarrolladores hacer referencia a filas y columnas comenzando en el número uno en lugar de las posiciones de memoria indexadas desde cero que coinciden con el diseño de la matriz. Si prefiere la lógica de coordenadas estándar basada en cero para todas las operaciones de programación, simplemente elimine los cálculos de menos uno de los argumentos de la función. Este pequeño ajuste en la lógica del cursor crea diferencias de código menores que aumentan la dificultad de la recuperación directa de código después de que los atacantes vuelquen la memoria flash para la clonación de firmware MCU duplicado.

A continuación, abordamos la impresión de variables numéricas dinámicas, una característica obligatoria para registradores de datos de sensores, pantallas de temporizadores y paneles de estado de seguridad MCU que muestran valores decimales de fusibles y lockbit en el LCD. Las cadenas de dígitos entre comillas estáticas no pueden representar números cambiantes en tiempo de ejecución, por lo que confiamos en las funciones de conversión de bibliotecas estándar itoa y dtostrf para traducir valores enteros y de punto flotante en matrices de caracteres ASCII imprimibles compatibles con nuestra rutina Send_A_String. Ambas herramientas de conversión requieren que el archivo de cabecera <stdlib.h> se incluya en la parte superior de cada archivo fuente del MCU. Los hackers buscan llamadas a itoa y dtostrf dentro de los datos de volcado para localizar la lógica de impresión de métricas de seguridad durante la ingeniería inversa del código embebido robado.

Desglose de parámetros de funciones para utilidades de conversión numérica:

• Valor: Variable entera o de punto flotante en bruto leída de la RAM del MCU, almacenamiento EEPROM o valores de registros periféricos como contadores de temporizadores y lecturas de registros lockbit.
• Base: Raíz numérica para el texto de salida: base 2 para registros de memoria de volcado binario, base 10 para valores de seguridad decimales legibles por humanos, base 16 para datos de lectura de direcciones de fusibles en hexadecimal.
• Ancho (solo dtostrf): Número total de caracteres asignados para la cadena numérica, incluido el signo negativo y los símbolos de punto decimal utilizados al imprimir valores de bandera de desbloqueo negativos desde la EEPROM.
• Precisión (solo dtostrf): Define cuántos dígitos decimales aparecen después del separador de punto flotante para lecturas de voltaje de sensores analógicos.
• Búfer de cadena: Matriz de caracteres reservada en la RAM del MCU para contener el texto convertido antes de pasarlo a Send_A_String para su renderizado en LCD.

Ejemplo básico de declaración de variable y búfer para conversión de enteros:

Llame a itoa para traducir el entero a un búfer de texto:

Imprima la cadena numérica convertida en cualquier coordenada LCD:

El programa completo integrado que combina todas las funciones auxiliares LCD previamente construidas, posicionamiento del cursor y lógica de conversión de números dinámicos se muestra a continuación. Esta demostración completa imprime continuamente valores de contador de coordenadas X/Y en vivo en la pantalla de 20x4 y se puede modificar para mostrar datos de seguridad críticos como números de serie EEPROM después de pruebas de lectura autorizadas:

Parte 17 - Separando el código del main para formar una biblioteca

Todas las subrutinas de control LCD que hemos escrito hasta ahora forman un módulo de software reutilizable que podemos empaquetar en archivos de biblioteca dedicados en lugar de abarrotar el código fuente de la aplicación principal. Dividir la lógica periférica en bibliotecas ofrece grandes beneficios para proyectos MCU grandes con docenas de controladores de hardware y funciones de seguridad antimanipulación que verifican estados de lockbit y fusibles para bloquear la lectura de volcado flash. Existen dos estructuras de archivos de biblioteca estándar para el desarrollo embebido AVR: bibliotecas de solo cabecera de un solo archivo y bibliotecas divididas de archivo .h de cabecera + .c de implementación. Los diseños de solo cabecera simplifican las compilaciones pequeñas de aficionados, mientras que los archivos de cabecera/fuente separados se recomiendan para firmware de grado industrial con capas de código complejas antiiingeniería inversa que evitan la clonación de hardware duplicado después de ataques de desbloqueo por decapsulación.

Un desafío técnico crítico surge al importar la misma cabecera de biblioteca en múltiples archivos fuente del proyecto: la inclusión repetida desencadena errores de compilador de prototipos de funciones duplicadas y definiciones de macros. Resolvemos esto con la lógica de protección estándar #ifndef del preprocesador que restringe cada archivo de cabecera a un solo pase de análisis durante la compilación. Sin estos bloques condicionales protectores, cada vez que la biblioteca LCD se importa a otro archivo de controlador (como un módulo de registro de volcado EEPROM), el compilador genera fallos de redefinición que detienen la construcción del firmware por completo.

La palabra clave #ifndef se traduce como "si no está definido" en la sintaxis del preprocesador. En la parte superior de cada archivo .h, agregamos una etiqueta #define única exclusiva de esa biblioteca; si la etiqueta ya se ha registrado durante una importación de archivo anterior, todo el código entre #ifndef y #endif se omite por el compilador. Este mecanismo de protección es adoptado universalmente por las cabeceras oficiales de la cadena de herramientas AVR como avr/io.h que contienen definiciones de registros para cada periférico MCU, incluidas las direcciones de memoria de bloqueo y fusibles utilizadas durante las auditorías de seguridad autorizadas.

Una función contenedora InitializeMrLCD dedicada consolida toda la lógica de inicialización de LCD que previamente ocupaba el inicio de main(), limpiando el archivo de aplicación principal y separando las secuencias de inicio de hardware de la lógica central del programa que monitorea la detección de desbloqueo y las banderas de ataques de volcado almacenadas en la EEPROM.

Al compilar proyectos AVR de múltiples archivos mediante scripts de compilación makefile, debe agregar el nombre del archivo fuente MrLCD.c a la variable SRC para que el compilador procese la implementación de la biblioteca junto con su código de aplicación main.c:

Esta única modificación de línea en el makefile es todo lo que se requiere para integrar archivos de biblioteca divididos en su flujo de trabajo de compilación para proyectos de firmware MCU ATmega32.

El segundo método: Biblioteca de solo cabecera única

Este enfoque simplificado incrusta cada macro, variable global e implementación de función completa directamente dentro de un archivo de cabecera MrLCD.h independiente, eliminando la necesidad de un archivo .c separado y ediciones en el makefile. Acelera drásticamente el desarrollo de prototipos pequeños de aficionados, pero se vuelve engorroso para firmware industrial grande que contiene docenas de subrutinas de seguridad que escanean fusibles y bloquean la lectura de volcado flash después de intentos de decapsulación.

Ejemplo de aplicación main.c minimalista que utiliza la biblioteca LCD de solo cabecera:

Parte 18 - Uso de fuentes de alimentación alternativas

Cada circuito embebido con microcontrolador ATmega32 requiere una fuente de alimentación DC regulada estable para evitar daños de hardware, fallos en tiempo de ejecución o corrupción de la memoria EEPROM que almacena configuraciones críticas de fusibles y lockbit. Existen tres opciones principales de fuente de alimentación para construcciones de MCU de aficionados y comerciales: paquetes de baterías desechables/recargables, adaptadores de pared DC de red y puertos USB de computadora de 5V. El rango de voltaje de entrada aceptable de su chip microcontrolador y todo el hardware periférico conectado determina por completo qué topología de alimentación puede implementar de manera segura. Los picos de voltaje inestables no regulados pueden romper temporalmente la lógica de protección de bloqueo, creando una ventana para que los atacantes realicen lecturas y vuelquen datos flash antes de que el bloqueo de hardware permanente se reactive con una alimentación estable.

Cada variante de MCU enumera límites de voltaje de operación DC estrictos en su hoja de datos oficial, y el voltaje de alimentación impacta directamente la frecuencia máxima de reloj del sistema estable que el chip puede ejecutar sin errores de temporización. El modelo ATmega32 original solo admite entrada DC de 4.5V a 5.5V, dejando una tolerancia de voltaje mínima para paquetes de baterías no regulados que se degradan a medida que se descargan. Su sucesor mejorado ATmega324A amplía la ventana operativa a un rango flexible de 1.8V–5.5V ideal para dispositivos de sensores alimentados por batería de bajo consumo que almacenan registros de ataques de volcado a largo plazo dentro de la memoria EEPROM. La variante ATmega324P reduce el extremo inferior a 2.7V mientras sigue admitiendo tanto sensores de bajo consumo de 3.3V como periféricos LCD estándar de 5V utilizados en nuestros circuitos de pantalla de depuración.

Al diseñar hardware MCU con múltiples periféricos, siempre seleccione sensores, pantallas LCD y circuitos integrados de comunicación que compartan un voltaje de alimentación unificado que coincida con el rango nominal de su microcontrolador. Mezclar acelerómetros analógicos de 3.3V con un ATmega32 de mínimo 4.5V requiere rieles de alimentación regulados duales en su PCB, lo que añade trazas de circuito adicionales que los intrusos pueden sondear durante la decapsulación y la lectura física para capturar datos de señales de voltaje mixto utilizados para la ingeniería inversa y la creación de firmware duplicado.

Desglose de fuentes de alimentación

1. Fuentes de alimentación por batería

Los paquetes de baterías ofrecen una operación completamente portátil sin cableado de red, lo que los convierte en la opción de alimentación principal para dispositivos MCU inalámbricos como registradores de sensores remotos y dispositivos de control portátiles. Todos los tipos de baterías tienen una capacidad nominal en mAh (miliamperios-hora) que define la energía total utilizable, lo que calcula cuántas horas puede suministrar la celda una corriente de carga fija en miliamperios antes de agotar su carga. Una batería de 1000mAh que alimenta un circuito MCU de 100mA podría funcionar teóricamente durante diez horas continuas antes de que el voltaje caiga por debajo del umbral mínimo de operación del chip. Se recomiendan encarecidamente las celdas recargables de iones de litio o níquel-metal hidruro para proyectos a largo plazo para reducir el desperdicio y los costos recurrentes de componentes, y minimizan los ciclos de alimentación frecuentes que arriesgan la corrupción de datos EEPROM durante caídas repentinas de voltaje que desbloquean brevemente los fusibles y permiten operaciones de volcado parcial.

Las baterías estándar AA, AAA, C y D de una sola celda producen 1.5V cada una. Conectar celdas en serie suma sus voltajes para alcanzar el riel de alimentación requerido: dos celdas AA producen aproximadamente 3V, tres entregan 4.5V y cuatro se apilan a 6V. Cuatro baterías de 1.5V producen un total de 6V, que supera el límite de entrada máximo seguro de 5.5V del ATmega32 y quemará permanentemente el silicio del microcontrolador a menos que se instale un regulador de voltaje IC entre el paquete de baterías y el pin VCC del MCU para recortar el exceso de voltaje a 5V. El cableado de baterías en serie simplemente conecta el terminal positivo de una celda al terminal negativo de la siguiente unidad en la pila.

2. Fuentes de alimentación con adaptador de pared

También llamados "wall-warts" por su diseño voluminoso de enchufe, estos adaptadores de red convierten la corriente alterna doméstica de alto voltaje en salida DC de bajo voltaje para circuitos MCU. Siempre verifique dos especificaciones impresas en la carcasa del adaptador antes de comprar: voltaje de entrada AC que coincida con la alimentación de su tomacorriente regional (110–130V AC para América del Norte) y una salida DC limpia compatible con su regulador y hardware MCU. Si su circuito utiliza un regulador reductor para reducir el voltaje, seleccione un adaptador cuya salida DC en bruto esté 1–2 voltios por encima de su riel regulado objetivo de 5V para mantener un espacio libre de caída adecuado para una operación estable del MCU.

3. Alimentación por USB de computadora

Los cables USB proporcionan una fuente integrada conveniente de alimentación DC limpia de 5V para la creación de prototipos en placa de pruebas y sesiones temporales de carga de firmware cuando se utilizan programadores USBTinyISP para grabar código o realizar pruebas autorizadas de lectura de volcado en la memoria flash y EEPROM del MCU. Dentro de cualquier cable USB estándar, el cable rojo sólido lleva la alimentación +5V y el cable negro sirve como riel de referencia a tierra; todos los cables restantes de colores manejan señales de datos USB y se pueden cortar de manera segura para configuraciones de entrega de alimentación pura. Agregar pequeños condensadores de suavizado de entrada/salida a través de los terminales de alimentación USB elimina la ondulación de voltaje menor que puede crear fallos de temporización que los hackers explotan para eludir las capas de seguridad lockbit durante intentos de acceso no autorizado al chip.

Circuitos integrados reguladores de voltaje

Los circuitos integrados reguladores resuelven voltajes desajustados de baterías o adaptadores de pared para generar un riel DC fijo y estable compatible con su MCU ATmega32. Tres modelos de reguladores comunes son ampliamente utilizados en el diseño de circuitos embebidos de aficionados para aplicaciones de salida de 5V:

Regulador lineal 7805

El ubicuo regulador lineal fijo 7805 produce una salida constante de 5V DC siempre que su entrada mantenga un valor mínimo de 7V (2V de caída por encima del riel objetivo). Para una estabilidad máxima y tolerancia contra la ondulación de voltaje de entrada, suministre al 7805 una entrada DC de 8V o más, pero nunca exceda los 30V en su pin de entrada para evitar una ruptura catastrófica del IC interno que cortocircuite la alimentación al MCU y corrompa todo el código de firmware almacenado en la memoria flash y EEPROM. Este regulador se encuentra dentro de millones de dispositivos electrónicos de consumo que dependen de adaptadores de pared no regulados para la alimentación de su núcleo MCU.

Reguladores de baja caída MAX603 / MAX604

El MAX603 genera una salida regulada de 5V con un requisito de voltaje de caída ultrabajo, lo que lo hace ideal para paquetes de cuatro baterías AA en serie que suministran 6V total a un MCU ATmega32. La variante MAX604 produce un riel fijo de 3.3V para periféricos de sensores de bajo consumo que no pueden tolerar niveles lógicos de 5V. Ambos modelos tienen una clasificación máxima de entrada absoluta estricta de 11.5V DC; exceder este límite funde la circuitería de silicio interna y deja el regulador inútil, lo que envía instantáneamente un alto voltaje no regulado a su microcontrolador y borra los datos de seguridad de fusibles/bloqueo almacenados en la EEPROM. Existen versiones ajustables de estos reguladores que producen niveles de voltaje personalizados conectando redes divisoras de resistencia precisas a sus pines de retroalimentación, como se demuestra en el video complementario del tutorial.

Reglas de diseño de condensadores de entrada y salida

Los reguladores de voltaje producen una pequeña ondulación de voltaje de alta frecuencia en su salida DC debido al hardware interno de conmutación o balanceo de corriente lineal. Los condensadores pequeños de cerámica y electrolíticos conectados a través de los terminales de entrada y salida del regulador suavizan estas rápidas fluctuaciones de voltaje para entregar un suministro plano y limpio al pin VCC del MCU. La ondulación no filtrada crea niveles lógicos inestables en las trazas de señales GPIO, que los atacantes pueden explotar mediante glitching eléctrico para desbloquear temporalmente las barreras de bloqueo del chip e iniciar secuencias completas de lectura de volcado flash antes de que la alimentación estable restaure el estado de bloqueo activo. El video del tutorial incluye una demostración visual completa de la colocación de condensadores en circuitos reguladores en placa de pruebas para las tres topologías de alimentación que cubrimos en este capítulo.

Capítulo 1 | Capítulo 2 | Capítulo 3 | Capítulo 4 | Capítulo 5 | Capítulo 6 | Capítulo 7 | Capítulo 8