themalwareguardian/cve-2025-70330Bogue d'analyse de fichier d'Easy Grade Pro 4.1 utilisé comme exemple pédagogique pour montrer comment les débutants peuvent commencer la recherche de vulnérabilités par rétro-ingénierie.
Un exemple éducatif créé pour montrer aux débutants que la recherche de vulnérabilités par rétro-ingénierie est possible dès le début.
Ce dépôt vient du besoin d'avoir un exemple simple qui pourrait être utilisé lors de l'enseignement aux débutants qui commencent dans la recherche de vulnérabilités, en particulier ceux qui s'intéressent à la rétro-ingénierie.
Après avoir terminé un cours, une formation ou un master lié à l'exploitation binaire ou à l'analyse binaire, de nombreux étudiants ont le sentiment que la recherche de vulnérabilités réelles est quelque chose de bien au‑delà de leur niveau. Ils associent généralement la rétro-ingénierie à des sujets très avancés tels que les vulnérabilités du noyau, l'exploitation de navigateurs, la recherche de firmware ou des cibles modernes complexes, et de ce fait, ils pensent ne pas être encore prêts. En pratique, le problème n'est pas le manque de connaissances, mais le manque d'un point de départ réaliste.
Je voulais un exemple qui puisse montrer qu'avec les compétences acquises lors d'un cours de base, il est déjà possible de prendre un vrai programme, de comprendre son fonctionnement, de déclencher un crash et d'identifier un vrai bug.
Ce dépôt est exactement ce genre d'exemple. Il ne s'agit pas de trouver une vulnérabilité complexe. Il s'agit de montrer que les débutants peuvent partir de quelque chose de petit, reproductible et compréhensible, tout en faisant de la vraie recherche de vulnérabilités.
Ce dépôt est directement lié à ma présentation « The Path That Leads to Your First CVE », où j'explique qu'il existe de multiples façons d'entrer dans le monde de la recherche de vulnérabilités, et que chaque personne finit généralement par suivre un chemin différent selon ses intérêts.
Certaines personnes commencent par l'audit de code source, d'autres par la rétro-ingénierie, d'autres par la sécurité web, et d'autres par la recherche technologique. Tous ces chemins sont valides, mais l'important est de comprendre que chaque domaine a aussi des points d'entrée adaptés aux débutants.
Exemples de parcours pour débutants :
Ces types de cibles peuvent sembler basiques, mais ils enseignent les mêmes compétences fondamentales qui seront nécessaires plus tard lors du travail sur des systèmes complexes.
Ce dépôt représente l'un de ces parcours pour débutants dans le domaine de la rétro-ingénierie.
La vulnérabilité documentée ici a été trouvée en analysant une ancienne application, en comprenant comment son format de fichier est analysé et en identifiant une erreur de programmation qui conduit à un crash. L'impact en lui‑même n'est pas complexe, mais le processus est réel, reproductible et utile pour apprendre comment fonctionne réellement la recherche de vulnérabilités.
C'est le type d'exemple que j'utilise lorsque j'explique « The Path That Leads to Your First CVE », pour montrer que la rétro-ingénierie est un chemin valide dès le début, et que commencer par des cibles simples est non seulement acceptable, mais souvent la meilleure façon d'apprendre.
Lorsque vous débutez, les applications modernes sont souvent trop complexes. Elles utilisent des protections, des mesures d'atténuation et des bases de code difficiles à comprendre sans beaucoup d'expérience. Les anciens logiciels sont différents.
Les applications héritées n'ont pas été écrites avec les pratiques de sécurité modernes à l'esprit. Elles contiennent souvent des bugs d'analyse simples, des opérations mémoire non sécurisées et des erreurs logiques qui peuvent être comprises avec des compétences de base en rétro-ingénierie. Cela les rend parfaits pour apprendre.
Avec un ancien programme, vous pouvez : rétro-concevoir le binaire, comprendre le format de fichier, déclencher un crash, analyser le crash, localiser le bug, documenter le problème et signaler la vulnérabilité. En d'autres termes, vous apprenez les compétences fondamentales dont tout chercheur en vulnérabilités a besoin.
C'est exactement ce que cet exemple illustre.
Cet exemple est important car il montre quelque chose de très simple :
Si vous aimez la rétro-ingénierie, vous pouvez suivre cette voie dès le début. Il faudra peut‑être des années pour la maîtriser, mais vous n'avez pas besoin d'attendre des années pour commencer à faire du vrai travail.
La vulnérabilité (CVE-2025-70330) affecte la logique d'analyse de fichier d'Easy Grade Pro 4.1 lors du chargement de fichiers de notes propriétaires .EGP.
L'application reconstruit les structures internes du carnet de notes en lisant des champs à positions fixes dans le fichier et en utilisant ces valeurs comme décalages dans le tampon du fichier chargé. Ces décalages sont ensuite utilisés pour calculer des tailles mémoire et copier des données dans des tampons alloués dynamiquement.
Dans des conditions normales, le fichier passe plusieurs vérifications structurelles avant que l'analyse ne continue. Cependant, une fois ces vérifications réussies, l'analyseur fait confiance aux valeurs de décalage stockées dans le fichier sans valider qu'elles restent dans les limites du tampon chargé.
En modifiant des octets spécifiques dans un fichier .EGP par ailleurs valide, il est possible de corrompre ces calculs de décalage internes. Lorsque l'analyseur utilise ensuite ces valeurs, il tente de lire de la mémoire en dehors de la région valide du fichier, ce qui entraîne une violation d'accès et un plantage de l'application.
Cette condition correspond à une lecture hors limites (CWE-125), entraînant un déni de service local lorsque le fichier modifié est ouvert.
Le format de fichier .EGP est analysé à l'aide d'une approche basée sur les décalages. Au lieu de traiter le fichier séquentiellement, l'analyseur lit des structures internes qui contiennent des décalages de début et de fin décrivant où des blocs de données spécifiques doivent se trouver dans le fichier.
Ces décalages sont utilisés pour calculer la taille d'une région mémoire et copier les données du tampon du fichier chargé vers une mémoire nouvellement allouée.
La logique vulnérable peut être résumée comme suit :
size = offset_end - offset_start + 1
buffer = calloc(1, size)
memcpy(buffer, file_buffer[offset_start - base_offset], size)
Une fois que le fichier a passé les vérifications initiales, l'analyseur suppose que les décalages stockés dans le fichier sont valides. Aucune vérification n'est effectuée pour s'assurer que le pointeur source calculé reste à l'intérieur du tampon du fichier chargé.
Si les décalages sont manipulés de manière contrôlée, l'analyseur peut tenter de lire de la mémoire en dehors de la région valide, provoquant une violation d'accès lors de l'opération memcpy().
Tous les fichiers .EGP malformés ne déclenchent pas le crash.
L'analyseur effectue plusieurs vérifications de cohérence avant d'atteindre le chemin de code vulnérable. Si la structure du fichier est trop corrompue, l'application arrête l'analyse prématurément et signale que le carnet de notes est endommagé.
Cependant, certaines modifications maintiennent les structures internes suffisamment cohérentes pour passer les vérifications initiales, tout en produisant des valeurs de décalage incorrectes plus tard dans le processus d'analyse.
Lorsque cela se produit, l'analyseur atteint des routines plus profondes où ces décalages sont considérés comme fiables et utilisés dans des opérations de copie mémoire, provoquant finalement la lecture hors limites.
Le crash peut être déclenché en modifiant un fichier .EGP valide et en insérant des données contrôlées à un décalage spécifique.
La preuve de concept fonctionne de la manière suivante :
Exemple de paramètres utilisés dans la PoC :
Cette modification maintient le fichier suffisamment valide structurellement pour passer les vérifications initiales, mais corrompt les calculs de décalage internes utilisés ultérieurement par l'analyseur, provoquant finalement le plantage de l'application.
Lorsque le fichier malformé est ouvert sous un débogueur, l'application plante lors d'une opération de copie mémoire.
L'exception observée est une violation d'accès causée par une lecture mémoire invalide.
Pendant le débogage, le pointeur invalide utilisé par memcpy() provient de calculs de décalage dérivés des structures du fichier analysé. Lorsque ces décalages référencent de la mémoire en dehors du tampon du fichier chargé, le pointeur source pointe vers une adresse non mappée, provoquant le crash.
Cela confirme que la vulnérabilité est causée par l'absence de validation des limites lors de l'analyse du fichier.
Cette vulnérabilité affecte un produit en fin de vie qui n'est plus maintenu par le fabricant.
Le problème est documenté à des fins éducatives et de recherche, et pour donner aux débutants un exemple concret de la façon dont un logiciel peut être analysé étape par étape pour comprendre comment les bugs apparaissent et comment les vulnérabilités réelles sont trouvées.