Análisis nativo con REA: ¿qué activa «File too large»?

01. Usar el error como punto de entrada

Una aplicación rechaza un archivo. Su interfaz dice «File too large» (archivo demasiado grande), pero ¿se refiere a bytes, píxeles decodificados, tamaño comprimido o un límite del servicio? Recupera la decisión antes de cambiar tu propia implementación.

Elige un mensaje exacto de tu objetivo. Busca entre las cadenas analizadas por el motor nativo. La ausencia de resultados no demuestra que el mensaje no exista: puede estar localizado, codificado, construido durante la ejecución o almacenado fuera del ejecutable.

npx -y rea-agents@6.4.0 search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. Encontrar la función que usa la cadena

Toma la dirección del resultado de búsqueda e inspecciona sus referencias. Una referencia puede apuntar a una función auxiliar genérica que muestra errores en vez de al control real. Sigue quien la invoca hasta encontrar la rama que decide si informar del error.

Los marcadores de posición siguientes deben sustituirse por direcciones devueltas para tu binario. Las direcciones de otra compilación no son intercambiables.

npx -y rea-agents@6.4.0 xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y rea-agents@6.4.0 decompile "/absolute/path/program" --procedure="RETURNED_FUNCTION_ADDRESS" --provider ghidra --format json

03. Recuperar la comparación, incluidas sus unidades

Identifica ambos lados de la comparación. Sigue de dónde viene el valor de tamaño, si se realizan operaciones aritméticas antes de comparar y si la rama usa mayor que o mayor o igual que. Esos detalles determinan el caso límite.

Trata los nombres y tipos descompilados como hipótesis de trabajo. Si el resultado está incompleto, inspecciona las instrucciones de la función seleccionada y las funciones que invoca. El uso de signo, el ancho entero y el orden de conversión pueden cambiar el resultado aunque el pseudocódigo parezca sencillo.

Usa las pruebas de función devueltas para explicar la rama que emite este error. Sigue el valor comparado hasta su entrada. Identifica el umbral, las unidades, el uso de signo y la comparación exacta. Si la descompilación está incompleta, inspecciona las instrucciones y la función auxiliar relevante. Cita direcciones y marca los tipos sin resolver en vez de adivinarlos.

04. Probar el límite, además del caso ideal

Si la regla recuperada usa un umbral L, prueba L−1, L y L+1 en las unidades reales de la entrada. Prueba también cero y entradas mal formadas donde la aplicación las admita. Hazlo solo en tu copia controlada del programa.

Para un control de tamaño de archivo, registra los bytes del archivo y el resultado observado. Para un control de imagen decodificada, variar solo los bytes del archivo puede no ejercitar la condición relevante. Compara la misma entrada con tu sustitución y guarda las diferencias.

• L−1: ¿aceptado o rechazado?
• L: ¿se acepta la igualdad?
• L+1: ¿qué error se devuelve?
• ¿Falla antes la entrada mal formada en otra rama?

05. Ajustar la conclusión al alcance de las pruebas

Tu entrega consiste en una regla recuperada y las pruebas ejecutadas sobre ella. Este flujo no se ha ejecutado sobre un objetivo concreto para este artículo; el texto del error es un escenario que debes sustituir por el tuyo.

Como ejemplo real de esta misma disciplina, el proyecto REA documenta la función de panorama sonoro de DX-Ball: su informe distingue 3205 comprobaciones diferenciales de entrada de una coincidencia separada de 63 bytes del compilador. Ninguna afirmación significa que se haya reconstruido todo el juego. Consulta la guía nativa oficial enlazada y su caso práctico para ver esa investigación.