FR 3134905 A1 20231027 FR 2203894 A 20220426 Procédé de protection d’un code source d’un programme informatique La présente invention concerne un procédé de protection (1) d’un code source (2) d’un programme informatique, comprenant : une première étape de conversion du code source (2) en un premier langage informatique, appelée première conversion (3), une première étape de protection (4) du premier langage informatique, une deuxième étape de conversion du premier langage informatique protégé par la première étape de protection (4) en un deuxième langage informatique, appelée deuxième conversion (5), une deuxième étape de protection (6) du deuxième langage informatique, une troisième étape de conversion du deuxième langage informatique protégé par la deuxième étape de protection (6) vers le premier langage informatique, appelée troisième conversion (7), une étape d’harmonisation (10) entre la première conversion (3) et la troisième conversion (7). (figure 1) Procédé de protection d’un code source d’un programme informatique La présente invention se rapporte au domaine des programmes informatiques et porte plus particulièrement sur un procédé de protection du code source de tels programmes informatiques. Un programme ou un logiciel informatique est créé à partir d’un code source rédigé par un informaticien. Par la suite, ce code source est compilé, c’est-à-dire que le code source est converti de sorte à être lisible par une machine informatique. Cette dernière peut ainsi exécuter le code compilé afin de mettre en œuvre ledit programme informatique. Les codes sources de certains programmes ou logiciels peuvent être convoités par des concurrents ou d’autres personnes mal intentionnées. Il existe ainsi des programmes qui permettent de décompiler un programme exécutable par une machine afin d’obtenir le code source. Ce dernier est alors connu et peut être volé ou réutilisé à des fins illégales. Afin de protéger les codes sources des programmes informatiques, plusieurs techniques peuvent être utilisées. L’une de ces techniques est appelée obfuscation et consiste à mettre en œuvre un ou plusieurs changements dans le code source, tels qu’une interversion des lignes du code ou un rajout de lignes de code uniquement destiné à perturber la décompilation. Une telle obfuscation est ainsi efficace contre la décompilation. Mais il existe maintenant des programmes capables de détecter les différentes méthodes d’obfuscation et de décompiler le programme afin de retrouver le code source malgré lesdites obfuscations. Il est ainsi nécessaire de perfectionner l’obfuscation du code source afin d’améliorer la protection de celui-ci et d’éviter les décompilations abusives. Les obfuscations doivent par ailleurs être mises en œuvre sans que cela porte atteinte à l’exécution du programme obfusqué, ni à sa rapidité d’exécution. La présente invention permet de renforcer la protection d’un code source en proposant un procédé de protection d’un code source d’un programme informatique, comprenant : une première étape de conversion du code source en un premier langage informatique, appelée première conversion, une première étape de protection du premier langage informatique, une deuxième étape de conversion du premier langage informatique protégé par la première étape de protection en un deuxième langage informatique, appelée deuxième conversion, une deuxième étape de protection du deuxième langage informatique, une troisième étape de conversion du deuxième langage informatique protégé par la deuxième étape de protection vers le premier langage informatique, appelée troisième conversion, une étape d’harmonisation entre la première conversion et la troisième conversion. Le procédé selon l’invention assure ainsi une protection renforcée du code source d’un programme tiers nécessitant d’être protégé. Par code source il faut comprendre le code réalisé par une personne et qui est par la suite compilé pour être exécutable par une machine. La pluralité de conversions et d’étapes de protection assure une protection finale optimale et pouvant être difficilement décompilée afin de parvenir au code source protégé. Le code source est dans un premier temps converti vers le premier langage informatique, exécutable par une machine virtuelle, puis est protégé une première fois. Les techniques de protection peuvent être diverses. Le procédé de protection convertit ensuite le premier langage informatique vers le deuxième langage informatique puis applique une deuxième étape de protection avant d’effectuer une reconversion vers le premier langage informatique. Ce sont particulièrement la deuxième conversion, la deuxième étape de protection et la troisième conversion qui maximisent la protection conférée au code source. Il est en effet difficile de détecter et contourner des techniques de protection qui ont été effectuées dans un autre langage informatique que celui qui est à première vue le langage exécutable souhaité. L’étape d’harmonisation permet quant à elle de vérifier si les différentes étapes de conversion et de protection n’ont pas nui à l’exécution du programme informatique. La troisième conversion, c’est-à-dire le programme une fois toutes les étapes de conversion et de protection effectuées est comparé à la première conversion, c’est-à-dire le programme après la première conversion avant toute étape de protection. Si l’étape d’harmonisation est un succès, cela signifie que le programme est toujours exécutable malgré les différentes étapes de conversion et de protection. Le code final est alors obtenu et assure une protection optimale contre la rétroingénierie, c’est-à-dire l’ensemble de techniques permettant d’obtenir le code source dudit programme informatique à partir de son code final. Selon une caractéristique du procédé, celui-ci comprend une troisième étape de protection du premier langage informatique mise en œuvre après la troisième conversion et avant l’étape d’harmonisation. La troisième étape de protection renforce la protection du code. Celle-ci se fait une fois que la troisième étape de conversion vers le premier langage informatique est effectuée. La troisième étape de protection est impérativement à effectuer avant l’étape d’harmonisation, cette dernière devant être effectuée après toute étape de conversion ou de protection. Selon une caractéristique du procédé, au moins l’une des étapes de protection est mise en œuvre par obfuscation. L’obfuscation consiste à effectuer une ou plusieurs actions pour brouiller le code obfusqué en y ajoutant de fausses informations afin de rendre la rétroingénierie plus difficile. A titre d’exemples, l’obfuscation peut consister en une inversion des lignes de code du programme ou en un ajout de lignes de code n’entrant pas en compte dans l’exécution du code. Les obfuscations peuvent porter atteinte à l’exécution du code, d’où l’intérêt de la phase d’harmonisation. Selon une caractéristique du procédé, celui-ci comprend un profil de protection qui agit sur la complexité des étapes de protection. Le profil de protection peut être paramétrable manuellement ou peut être déterminé de manière semi-automatique en sélectionnant manuellement des paramètres préétablis. Selon une caractéristique du procédé, le profil de protection est déterminé en fonction d’un niveau de protection souhaité. Plus le niveau de protection souhaité est élevé, plus la complexité des étapes de protection est élevée. Le profil de protection peut ainsi être présélectionné avant le démarrage du procédé de procession, ou au moins avant la première étape de protection. Selon une caractéristique du procédé, l’étape d’harmonisation vérifie l’exécution correcte de la troisième conversion et compare cette exécution avec une exécution de la première conversion. Comme cela a été mentionné précédemment, l’étape d’harmonisation permet de vérifier que les différentes étapes de conversion et de protection n’ont pas nui à l’exécution du code. En effet, la mise en œuvre de différentes protections par obfuscation peut augmenter la taille du code ou le modifier au point de le rendre inutilisable. Au-delà de l’exécution correcte du code, l’étape d’harmonisation permet également de vérifier par exemple si les différentes conversions et protections n’ont pas nui à la vitesse d’exécution du code. Un seuil de tolérance peut être mis en place afin de déterminer si l’exécution du code après toutes les étapes de conversion et de protection est suffisamment rapide pour être considéré comme validé lors de l’étape d’harmonisation. Selon une caractéristique du procédé, celui-ci comprend une étape d’ajustement du profil de protection si l’étape d’harmonisation échoue. L’échec de l’étape d’harmonisation peut être due à une incapacité d’exécuter le code après la troisième conversion, ou à une exécution trop longue de celui-ci, ou à une exécution n’entraînant pas le résultat espéré. Si l’étape d’harmonisation échoue, cela signifie que les étapes de protection ont trop complexifié le code pour le maintenir exécutable. Les exigences de protection doivent donc être revues à la baisse. A ce titre, le profil de protection est ajusté afin de rendre les opérations de protection moins complexe de sorte à moins altérer le code du programme et que celui-ci demeure exécutable de manière optimale lors de la phase d’harmonisation. Selon une caractéristique du procédé, celui-ci est réinitialisé après l’étape d’ajustement du profil de protection si l’étape d’harmonisation échoue. Une fois que le profil de protection est ajusté, le procédé de protection est réinitialisé en prenant en compte les nouveaux paramètres du profil de protection agissant sur les étapes de protection. Le procédé est de nouveau intégralement effectué jusqu’à l’étape d’harmonisation incluse. Si celle-ci échoue de nouveau, le profil de protection est de nouveau ajusté et le procédé de nouveau réinitialisé jusqu’à ce que l’étape d’harmonisation soit mise en œuvre avec succès. Selon une caractéristique du procédé, le premier langage informatique et le deuxième langage informatique sont exécutables sur une machine virtuelle. D’une manière préférentielle, les deux langages informatiques sont suffisamment différents pour devoir être lus par deux machines virtuelles différentes. Le changement de langage informatique au cours du procédé de protection garantit le renforcement de la protection, car la rétroingénierie est beaucoup plus compliquée si un changement de langage informatique doit être pris en compte. Selon une caractéristique du procédé, le premier langage informatique est en langage Java™. Le langage Java™ est l’un des langages informatiques les plus couramment utilisés pour faire de la programmation. Le premier langage informatique peut toutefois être un langage de programmation quelconque, l’objectif étant de pouvoir mettre en œuvre le procédé de protection pour un maximum de langages informatiques. L’invention couvre également un support informatique comprenant au moins un compilateur, au moins un module de protection et au moins un module d’harmonisation, ledit support informatique mettant en œuvre le procédé de protection tel que décrit précédemment. Le compilateur permet d’opérer les conversions, le module de protection assure les étapes de protection, par exemple avec des techniques d’obfuscation, et le module d’harmonisation est chargé de mettre en œuvre l’étape d’harmonisation. Le module de protection peut également présenter la fonction de mise en œuvre du profil de protection et le module d’harmonisation peut mettre en œuvre l’ajustement dudit profil de protection. Le support informatique comprend par ailleurs une pluralité d’autres composants nécessaires à son fonctionnement. L’invention vise enfin un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé décrites dans le présent document, lorsque ledit programme est exécuté sur un ordinateur. D’autres caractéristiques et avantages de l’invention apparaîtront encore au travers de la description qui suit d’une part, et de plusieurs exemples de réalisation donnés à titre indicatif et non limitatif en référence aux dessins schématiques annexés d’autre part, sur lesquels : représente un logigramme d’un procédé de protection d’un code source selon l’invention, est une représentation schématique d’un support informatique apte à mettre en œuvre le procédé de protection. La est un logigramme illustrant un procédé de protection 1 selon l’invention. L’objectif de ce procédé de protection 1 est de protéger un code source 2 d’un programme informatique de manière à empêcher de retrouver ledit code source 2 par rétroingénierie. Pour ce faire, le procédé de protection 1 débute par une première étape de conversion, également appelée première conversion 3. La première conversion 3 consiste à convertir, ou compiler, le code source 2 en un premier langage informatique, exécutable par une machine virtuelle. La conversion d’un code source 2 en un premier langage informatique est donc indispensable pour que ledit code puisse être exécuté par une machine par la suite. Le premier langage informatique peut par exemple être un langage Java™. Une fois le premier langage informatique obtenu, celui-ci est protégé lors d’une première étape de protection 4. Cette dernière permet d’appliquer différents moyens de protection au code converti suite à la première conversion 3, et ce afin de compliquer une potentielle opération de rétroingénierie. Le code peut par exemple être protégé grâce à une ou plusieurs techniques d’obfuscation. L’obfuscation consiste à modifier les lignes du code, par exemple en les intervertissant, ou d’ajouter des lignes de code inutiles pour l’exécution du programme défini par ledit code. Le but de cette protection par obfuscation est d’induire en erreur toute tentative de rétroingénierie ayant pour but de retrouver le code source 2. Lorsque la première étape de protection 4 est effectuée, le procédé de protection 1 effectue une nouvelle conversion sur le code protégé lors de la première étape de protection 4. Cette nouvelle protection constitue une deuxième étape de conversion, ou deuxième conversion 5. Cette fois-ci, le premier langage informatique est converti en un deuxième langage informatique, différent du premier langage informatique. Le deuxième langage informatique est également exécutable par une machine virtuelle. Le changement de langage informatique au cours du procédé de protection 1 renforce davantage la sécurité du code source 2, car, pour un logiciel de rétroingénierie, cela ajoute un obstacle supplémentaire aux opérations de protection. Le deuxième langage informatique peut être n’importe quel langage, l’essentiel étant qu’il soit compatible avec le premier langage informatique pour une conversion de l’un vers l’autre. Une fois le deuxième langage informatique obtenu, une deuxième étape de protection 6 est mise en œuvre sur celui-ci. Les opérations effectuées lors de la deuxième étape de protection 6 peuvent être similaires à celles effectuées lors de la première étape de protection 4, la différence étant que la deuxième étape de protection 6 est mise en œuvre sur le deuxième langage informatique. Tout comme la première étape de protection 4, les techniques de protection appliquées lors de la deuxième étape de protection peuvent être des techniques d’obfuscation. Suite à cela, le procédé de protection 1 se poursuit avec une troisième étape de conversion, appelée troisième conversion 7. La troisième conversion 7 assure la conversion du deuxième langage informatique vers le premier langage informatique. Le retour au premier langage informatique est indispensable pour l’exécution convenable du code au terme du procédé de protection 1. Par ailleurs, il s’agit du langage informatique dans lequel est compilé le code source 2 lors de la première conversion 3. Une troisième étape de protection 8 peut être appliquée sur le code après la troisième conversion 7. Tout comme pour les étapes de protection précédentes, la troisième étape de protection 8 peut être mise en œuvre avec des techniques d’obfuscation. Cette troisième étape de protection 8 est optionnelle, mais elle contribue davantage à la protection du code source 2. La première étape de protection 4, la deuxième étape de protection 6 et la troisième étape de protection 8 sont en partie gérées par un profil de protection 9. Le profil de protection 9 est un paramétrage qui agit sur la complexité des étapes de protection 4, 6, 8. Plus une étape de protection 4, 6, 8 est complexe, plus les techniques de protection rendent difficiles la rétroingénierie du code source 2. Ainsi le profil de protection 9 peut être paramétré manuellement par un utilisateur, par exemple le créateur du code source 2, pour déterminer un niveau de protection que le procédé de protection 1 doit appliquer sur le code source 2. Un niveau de protection élevé demandé correspond ainsi à une complexité élevée des étapes de protection 4, 6, 8. Le profil de protection 9 peut par exemple être déterminé avant le déroulement du procédé de protection 1. Après l’éventuelle troisième étape de protection 8, le procédé de protection 1 met en œuvre une étape d’harmonisation 10. L’étape d’harmonisation 10 si le code est toujours fonctionnel malgré les différentes étapes de conversion et de protection appliquées sur celui-ci. Ces différentes étapes effectuent en effet de nombreux changements sur le code en lui-même, parfois au point de le rendre inopérable lors de l’exécution. D’une manière alternative, le code peut toujours être exécutable, mais peut également être trop long à s’exécuter, ce qui n’est pas convenable non plus. L’étape d’harmonisation 10 permet donc de vérifier si le code est toujours exécutable correctement et à une vitesse correcte. Pour se faire, lors de l’étape d’harmonisation 10, un exécutable de la troisième conversion 7, et après la troisième étape de protection 8 si celle-ci a lieu, est comparé à un exécutable de la première conversion 3. L’exécutable de la première conversion 3 correspond au code source 2 compilé et est donc utilisé comme comparatif pour vérifier si l’exécutable de la troisième conversion 7 s’effectue correctement. Si l’étape d’harmonisation 10 échoue, cela signifie que l’exécutable de la troisième conversion 7, après l’éventuelle troisième étape de protection 8, a été trop altérée pour être exécutée normalement. N’ayant pas un code fonctionnel à la fin du procédé de protection 1, celui-ci ne peut pas s’achever. Si l’exécution n’est pas possible ou est trop longue, cela signifie que les différentes étapes de protection 4, 6, 8 sont trop complexes et ont par exemple générés trop d’obfuscations ou des obfuscations trop complexes au point de nuire à son exécution. Autrement dit, le profil de protection 9 a été paramétré selon un niveau d’exigence de protection trop élevé pour ne pas nuire à l’exécution du code. Pour pallier ce problème, si l’étape d’harmonisation 10 échoue, le procédé de protection 1 met en œuvre une étape d’ajustement 11 du profil de protection 9. L’étape d’ajustement 11 permet d’agir sur le profil de protection 9 notamment en modifiant ses paramètres de sorte à diminuer les exigences de niveau de protection souhaité. En modifiant les paramètres du profil de protection 9, ce dernier diminue donc la complexité d’une ou plusieurs étapes de protection 4, 6, 8. Une fois l’étape d’ajustement 11 effectuée, le procédé de protection 1 est réinitialisé à partir de la première conversion 3. Le procédé de protection 1 se déroule de nouveau tel que cela a été décrit précédemment, mais avec des étapes de protection à la complexité moindre, le but étant d’obtenir un code exécutable à la fin du procédé de protection 1, tout en conservant une protection la plus élevée possible. De nouveau parvenu à l’étape d’harmonisation 10, la troisième conversion 7 est de nouveau comparé à la première conversion 3. Si l’étape d’harmonisation 10 échoue de nouveau, le procédé de protection 1 met de nouveau en œuvre l’étape d’adaptation 11 du profil de protection 9 afin de diminuer davantage le niveau d’exigence de protection et se réinitialise de nouveau. Cette opération est répétée tant que l’étape d’harmonisation 10 échoue. D’une manière avantageuse, le procédé de protection 1 peut être paramétré pour démarrer à un niveau de protection maximal, puis ce dernier peut être diminué progressivement à chaque fois que l’étape d’harmonisation 10 échoue, afin de garantir le meilleur compromis entre exécution correcte et niveau de protection. Lorsque l’étape d’harmonisation 10 se déroule avec succès, un code final 12 est alors obtenu. C’est le code final 12 qui est par exemple intégré dans un produit commercialisé et qui participe au fonctionnement du programme associé. Le code final 12 présente une protection renforcée contre la rétroingénierie. En effet une simple décompilation est insuffisante pour retrouver le code source 2 à partir du code final 12. Et même avec un programme de rétroingénierie par exemple capable de contourner les techniques d’obfuscation, l’accès au code source 2 demeure protégé du fait qu’au-delà des étapes de protection, il y a eu des étapes de conversion en un autre langage informatique, ici le deuxième langage informatique, avec une étape de protection au sein même de ce deuxième langage informatique. Il est ainsi particulièrement difficile pour un quelconque logiciel de rétroingénierie, aussi sophistiqué qu’il soit, de prendre en compte tous ces paramètres pour parvenir au code source 2. La est une représentation schématique d’un support informatique 13 apte à mettre en œuvre le procédé de protection décrit précédemment. Le support informatique 13 peut être un ordinateur, mais peut également être un support de stockage, tel qu’un disque dur ou une clé USB. Le support informatique 13 comprend une pluralité de composants nécessaire pour son fonctionnement propre. Le support informatique 13 comprend également au moins un compilateur 14, au moins un module de protection 15 et au moins un module d’harmonisation 16, qui ensemble sont aptes à mettre en œuvre le procédé de protection. Le compilateur 14 est chargé de l’ensemble des conversions survenant au cours du procédé de protection. Il peut y avoir plusieurs compilateurs 14 au sein du support informatique, chacun étant attribué à l’une des trois étapes de conversion. Le module de protection 15 est chargé de l’ensemble des étapes de protection. Le module de protection 15 est par exemple apte à mettre en œuvre des techniques d’obfuscation. Le module de protection 15 peut également intégrer les caractéristiques relatives au profil de protection. Le module d’harmonisation 16 quant à lui assure l’étape d’harmonisation. Le module d’harmonisation 16 peut aussi agir sur le module de protection 15 dans le cadre de l’étape d’ajustement dans le cas où l’étape d’harmonisation échoue, tel que cela a été décrit précédemment. Bien sûr, l’invention n’est pas limitée aux exemples qui viennent d’être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l’invention. L’invention, telle qu’elle vient d’être décrite, atteint bien le but qu’elle s’était fixée, et permet de proposer un procédé de protection d’un code source comprenant différentes étapes de conversion et de protection renforçant la sécurité dudit code source contre la rétroingénierie. Des variantes non décrites ici pourraient être mises en œuvre sans sortir du contexte de l’invention, dès lors que, conformément à l’invention, elles comprennent un procédé de protection conforme à l’invention. Procédé de protection (1) d’un code source (2) d’un programme informatique, comprenant : une première étape de conversion du code source (2) en un premier langage informatique, appelée première conversion (3), une première étape de protection (4) du premier langage informatique, une deuxième étape de conversion du premier langage informatique protégé par la première étape de protection (4) en un deuxième langage informatique, appelée deuxième conversion (5), une deuxième étape de protection (6) du deuxième langage informatique, une troisième étape de conversion du deuxième langage informatique protégé par la deuxième étape de protection (6) vers le premier langage informatique, appelée troisième conversion (7), une étape d’harmonisation (10) entre la première conversion (3) et la troisième conversion (7). Procédé de protection (1) selon la revendication 1, comprenant une troisième étape de protection (8) du premier langage informatique mise en œuvre après la troisième conversion (7) et avant l’étape d’harmonisation (10). Procédé de protection (1) selon la revendication 1 ou 2, au cours duquel au moins l’une des étapes de protection (4, 6, 8) est mise en œuvre par obfuscation. Procédé de protection (1) selon l’une quelconque des revendications précédentes, comprenant un profil de protection (9) qui agit sur la complexité des étapes de protection (4, 6, 8). Procédé de protection (1) selon la revendication précédente, au cours duquel le profil de protection (9) est déterminé en fonction d’un niveau de protection souhaité. Procédé de protection (1) selon la revendication 4 ou 5, au cours duquel l’étape d’harmonisation (10) vérifie l’exécution correcte de la troisième conversion (7) et compare cette exécution avec une exécution de la première conversion (3). Procédé de protection (1) selon l’une quelconque des revendications 4 à 6, comprenant une étape d’ajustement (11) du profil de protection (9) si l’étape d’harmonisation (10) échoue. Procédé de protection (1) selon la revendication précédente, caractérisé en ce que le procédé est réinitialisé après l’étape d’ajustement (11) du profil de protection (9) si l’étape d’harmonisation (10) échoue. Procédé de protection (1) selon l’une quelconque des revendications précédentes, au cours duquel le premier langage informatique et le deuxième langage informatique sont exécutables sur une machine virtuelle. Procédé de protection (1) selon l’une quelconque des revendications précédentes, selon lequel le premier langage informatique est en langage Java™. Support informatique (13) comprenant au moins un compilateur (14), au moins un module de protection (15) et au moins un module d’harmonisation (16), ledit support informatique (13) mettant en œuvre le procédé de protection (1) selon l’une quelconque des revendications précédentes. Programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé selon l’une quelconque des revendications 1 à 10, lorsque ledit programme est exécuté sur un ordinateur.