Analyse native avec REA : qu’est-ce qui déclenche « File too large » ?

01. Prenez l’erreur comme point d’entrée

Une application refuse un fichier. Son interface indique « File too large », mais parle-t-elle d’octets, de pixels décodés, de taille compressée ou d’une limite du service ? Retrouvez la règle de décision avant de modifier votre propre implémentation.

Choisissez un message exact de votre cible. Cherchez-le parmi les chaînes analysées par le moteur natif. Son absence des résultats ne prouve pas qu’il n’existe pas : il peut être traduit, encodé, assemblé à l’exécution ou stocké hors de l’exécutable.

npx -y [email protected] search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. Trouvez la fonction qui utilise la chaîne

Relevez l’adresse du résultat et inspectez ses références. Une référence peut mener à une fonction générale d’affichage d’erreur plutôt qu’au contrôle lui-même. Suivez l’appelant jusqu’à la branche qui décide de signaler l’erreur.

Remplacez les valeurs indicatives ci-dessous par les adresses renvoyées pour votre binaire. Les adresses d’une autre compilation ne sont pas interchangeables.

npx -y [email protected] xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y [email protected] decompile "/absolute/path/program" --procedure="RETURNED_FUNCTION_ADDRESS" --provider ghidra --format json

03. Retrouvez la comparaison et ses unités

Identifiez les deux côtés de la comparaison. Suivez l’origine de la taille, les éventuels calculs précédents et l’opérateur utilisé : strictement supérieur ou supérieur ou égal. Ces détails déterminent le cas limite.

Traitez les noms et types décompilés comme des hypothèses de travail. Si le résultat est incomplet, inspectez les instructions de la fonction et les fonctions appelées. Le caractère signé, la largeur des entiers et l’ordre des conversions peuvent changer le résultat même si le pseudocode paraît simple.

Utilise les éléments renvoyés sur la fonction pour expliquer la branche qui émet cette erreur. Remonte de la valeur comparée à son entrée. Identifie le seuil, les unités, le caractère signé et la comparaison exacte. Si la décompilation est incomplète, inspecte les instructions et la fonction auxiliaire concernée. Cite les adresses et signale les types non résolus au lieu de les deviner.

04. Testez la limite, pas seulement le cas nominal

Si la règle retrouvée utilise un seuil L, testez L−1, L et L+1 dans les unités réelles de l’entrée. Testez aussi zéro et les entrées mal formées là où l’application les accepte. Exécutez ces tests uniquement dans votre copie contrôlée du programme.

Pour une limite de taille de fichier, notez le nombre d’octets et le résultat observé. Pour une limite d’image décodée, changer seulement les octets du fichier ne sollicite pas forcément la bonne condition. Comparez la même entrée avec votre remplacement et conservez les écarts.

• L−1 : accepté ou refusé ?
• L : l’égalité est-elle acceptée ?
• L+1 : quelle erreur est renvoyée ?
• Une entrée mal formée échoue-t-elle plus tôt dans une autre branche ?

05. Limitez la conclusion à ce qui est démontré

Le livrable est une règle retrouvée et les tests exécutés sur cette règle. Cette méthode n’a pas été appliquée à une cible précise pour cet article ; le message d’erreur est un scénario à remplacer par le vôtre.

Pour un exemple réel de cette rigueur, le projet REA documente la fonction de panoramique de DX-Ball : son rapport distingue 3 205 comparaisons différentielles sur les entrées d’une correspondance séparée de 63 octets à la compilation. Aucun de ces résultats ne signifie que le jeu entier est reconstruit. Consultez le guide natif officiel et son étude de cas liés pour cette investigation.