Compilateurs Intel. Pourquoi de nouveaux compilateurs étaient-ils nécessaires ?

Compilateurs Intel C++ et Fortran et bibliothèque MKL

Outre les compilateurs GNU standard pour Linux, les compilateurs Intel C++ et Fortran sont installés sur les clusters du complexe informatique NIVC. Actuellement (début 2006), les compilateurs version 9.1 sont installés sur tous les clusters. Cette page est dédiée à la description des options et paramètres les plus importants de ces compilateurs, ainsi que leurs principales différences par rapport aux compilateurs GNU. La page s'adresse principalement aux utilisateurs des clusters MSU Research Computing Center, mais peut également être utile à d'autres utilisateurs russophones. Les problèmes liés à la compilation pour la plateforme IA-64 ne sont pas abordés ici.

De plus, la bibliothèque Intel est installée sur tous les clusters Bibliothèque mathématique du noyau(MKL) version 8.0.2. La bibliothèque se trouve dans le répertoire /usr/mkl. Veuillez noter que les sous-répertoires 32, 64 et em64t sont disponibles dans le répertoire lib. Sur le cluster Ant, vous devez utiliser les bibliothèques du sous-répertoire em64t et sur les autres clusters - du sous-répertoire 32. Toute la documentation et les exemples nécessaires peuvent être obtenus dans le répertoire /usr/mkl/doc.

Pourquoi de nouveaux compilateurs étaient-ils nécessaires ?

Le besoin de nouveaux compilateurs est apparu principalement pour a) prendre en charge la programmation en Fortran 90, et également b) pour une optimisation des programmes Fortran plus puissante que celle fournie par le compilateur g77, qui utilise la traduction en C puis la compilation à l'aide de gcc.

Les compilateurs PGI (Portland Group) répondent également à ces exigences, mais la société de développement a refusé de les fournir à la Russie.

Comment utiliser?

Les compilateurs Intel sont invoqués à l'aide de commandes cic(C ou C++), icpc(C++) et sifort(Fortran 77/90). Les commandes mpicc, mpiCC et mpif77 permettant de compiler et d'assembler des programmes MPI sont également configurées pour utiliser les compilateurs Intel.

Il est également possible d'utiliser des compilateurs GNU à l'aide des commandes mpigcc, mpig++ et mpig77 (Fortran 90 n'est pas supporté).

Fichiers d'entrée

Par défaut, les fichiers avec l'extension .cpp Et .cxx sont considérés comme des textes sources en langage C++, les fichiers avec l'extension .c- Le code source C et le compilateur icpc compile également les fichiers .c en tant que code source C++.

Fichiers avec extensions .F, .ftn Et .pour sont reconnus comme textes sources en langue Fotran, avec une forme de notation fixe, et les fichiers .fpp Et .F en outre passé par le préprocesseur du langage Fortran. Fichiers avec l'extension .f90 sont considérés comme des textes sources Fortran 90/95 avec notation de forme libre. Vous pouvez spécifier explicitement une forme de notation fixe ou libre pour les programmes Fortran à l'aide des options -FI Et -FR respectivement.

Fichiers avec l'extension .s reconnu comme code de langage assembleur pour l'IA-32.

Fonctionnalités du compilateur Intel

Nous présentons ici les caractéristiques des compilateurs Intel telles qu'indiquées par le développeur dans le manuel d'utilisation avec certains de nos commentaires.

• Optimisation significative
  Apparemment, cela signifie optimiser le code à un niveau élevé, c'est-à-dire tout d'abord, diverses transformations de boucles, que presque tous les compilateurs font avec plus ou moins de succès
• Optimisation en virgule flottante
  Apparemment, cela signifie avant tout l'utilisation maximale des commandes implémentées au niveau matériel
• Optimisations interprocédurales
  ceux. optimisation globale de l'ensemble du programme, par opposition à l'optimisation ordinaire, qui n'affecte que le code de fonctions spécifiques
• Optimisation basée sur le profil
  ceux. la possibilité d'exécuter un programme en mode test, de collecter des données sur le temps nécessaire pour transmettre certains fragments de code à l'intérieur de fonctions fréquemment utilisées, puis d'utiliser ces données à des fins d'optimisation
• Prise en charge du jeu d'instructions SSE dans les processeurs Pentium III
  remarque : pour les tâches informatiques, les commandes SSE2 sont plus intéressantes, c'est-à-dire commandes vectorielles sur des nombres réels 64 bits, mais elles ne sont prises en charge que sur les processeurs Pentium 4, que nous n'avons pas encore à notre disposition
• Vectorisation automatique
  ceux. encore une fois, en utilisant les commandes SSE et SSE2, insérées automatiquement par le compilateur
• Prise en charge d'OpenMP pour la programmation sur les systèmes SMP
  remarque : sur un cluster il est recommandé d'utiliser en priorité l'interface MPI ; une utilisation généralisée d'OpenMP sur le cluster n'est pas attendue et de telles expérimentations n'ont pas encore été réalisées ; mais il est probablement logique d'utiliser des bibliothèques (BLAS, etc.) parallélisées pour la mémoire partagée.
• Prélecture des données
  ceux. Apparemment, l'utilisation de commandes de préchargement de la mémoire dans le cache de données, qui sera nécessaire après un certain temps
• Code "Dispatching" pour différents processeurs
  ceux. la possibilité de générer du code pour différents processeurs dans un seul fichier exécutable, ce qui vous permet de profiter de les derniers processeurs pour obtenir les performances les plus élevées sur eux, tout en maintenant la compatibilité binaire des programmes avec les processeurs antérieurs ; Sur notre cluster, ce n'est pas encore pertinent, car seuls les processeurs Pentium III sont utilisés et les programmes compilés sur le cluster ne sont pas censés être transférés et exécutés sur d'autres machines

Options de base du compilateur

Les plus intéressantes sont bien entendu les options d’optimisation du code. La plupart des options sont communes aux compilateurs C++ et Fortran. Plus Description détaillée options dans les manuels d’utilisation en anglais.

Performance

Selon les résultats des tests SPEC CPU2000, publiés sur le serveur ixbt.com, les compilateurs Intel version 6.0 étaient presque universellement meilleurs par rapport aux compilateurs gcc versions 2.95.3, 2.96 et 3.1, et à la version PGI 4.0.2. Ces tests ont été réalisés en 2002 sur un ordinateur équipé d'un processeur Pentium 4/1,7 GHz et RedHat Linux 7.3.

Selon les tests effectués par Polyhedron, le compilateur Intel Fortran version 7.0 était presque universellement supérieur aux autres compilateurs Fortran 77 pour Linux (Absoft, GNU, Lahey, NAG, NAS, PGI). Ce n'est que dans certains tests que le compilateur Intel est légèrement inférieur aux compilateurs Absoft, NAG et Lahey. Ces tests ont été réalisés sur un ordinateur équipé d'un processeur Pentium 4/1,8 GHz et Mandrake Linux 8.1.

Les compilateurs Intel version 9.1 surpassent également les compilateurs gcc et affichent des performances comparables à celles d'Absoft, PathScale et PGI.

Nous serons reconnaissants aux utilisateurs et lecteurs qui nous envoient des données sur l'impact du choix du compilateur (GCC ou Intel) et des options d'optimisation sur la vitesse de travail sur leurs problèmes réels.

Bibliothèques

Le compilateur du langage C utilise une bibliothèque d'exécution développée au sein du projet GNU ( libc.a).

Les bibliothèques suivantes sont fournies avec le compilateur Intel C++ :

• libcprts.a- Bibliothèque de langage d'exécution C++ développée par Dinkumware.
• libcxa.a- bibliothèque d'exécution supplémentaire pour le développement C++ par Intel.
• libimf.a- une bibliothèque de fonctions mathématiques développées par Intel, qui comprend des implémentations optimisées et de haute précision de fonctions trigonométriques, hyperboliques, exponentielles, spéciales, complexes et autres (pour plus de détails, voir la liste des fonctions).
• libirc.a- prise en charge du runtime pour le profilage (PGO) et l'envoi de code en fonction du processeur (voir ci-dessus).
• libguide.a- Implémentation OpenMP.

Cette liste contient des bibliothèques statiques, mais pour la plupart d'entre elles il existe également des bibliothèques dynamiques, c'est-à-dire options connectées au démarrage ( .donc).

Les bibliothèques suivantes sont fournies avec le compilateur Fortran : libCEPCF90.a, libIEPCF90.a, libintrins.a, libF90.a, la bibliothèque de fonctions mathématiques libimf.a est également utilisée.

Construire le fichier exécutable

Les bibliothèques peuvent être connectées de manière statique (lors de la construction) ou dynamiquement (lors du démarrage du programme). L'approche dynamique vous permet de réduire la taille du fichier exécutable et de partager la même copie de la bibliothèque en mémoire, mais pour cela vous devez installer un ensemble complet de bibliothèques dynamiques utilisées sur chaque nœud où les programmes seront exécutés .

Ainsi, si vous avez installé le compilateur Intel sur votre machine Linux et souhaitez exécuter les fichiers exécutables compilés sur d'autres machines, vous devez alors soit utiliser une version statique (ce qui est plus simple), soit copier les bibliothèques dynamiques Intel sur ces machines (généralement à partir de un répertoire comme /opt/intel /compiler70/ia32/lib) vers l'un des répertoires répertoriés dans le fichier /etc/ld.so.conf, et assurez-vous également que le même ensemble de bibliothèques dynamiques GNU/Linux est installé sur ces machines .

Par défaut, toutes les bibliothèques de développement Intel (à l'exception de libcxa.so) sont liées de manière statique, et toutes les bibliothèques système Linux et bibliothèques GNU sont liées de manière dynamique. Utilisation de l'option -statique vous pouvez forcer le collecteur (éditeur de liens) à connecter toutes les bibliothèques de manière statique (ce qui augmentera le volume fichier exécutable), et en utilisant l'option -i_dynamique Vous pouvez lier dynamiquement toutes les bibliothèques de développement Intel.

Lors de la connexion de bibliothèques supplémentaires à l'aide de l'option d'affichage -bibliothèque vous devrez peut-être utiliser l'option -Lrépertoire pour spécifier le chemin où se trouvent les bibliothèques.

Utilisation des options -Bstatique Et -Bdynamique vous pouvez spécifier explicitement une connexion dynamique ou statique de chacune des bibliothèques spécifiées dans ligne de commande.

Utilisation de l'option -c l'assemblage du fichier exécutable est désactivé et seule la compilation est effectuée (génération de module objet).

Partage de modules en Fortran et C

Pour partager des modules écrits en Fortran et C, vous devez vous mettre d'accord sur la dénomination des procédures dans les modules objets, la transmission des paramètres et l'accès aux variables globales, le cas échéant.

Par défaut, le compilateur Intel Fortran convertit les noms de procédures en minuscules et ajoute un trait de soulignement à la fin du nom. Le compilateur C ne change jamais les noms de fonctions. Ainsi, si nous voulons appeler une fonction ou une procédure FNNAME implémentée en C à partir d'un module Fortran, alors dans le module C, elle doit être appelée fnname_.

Le compilateur Fortran prend en charge l'option -nus [nom de fichier], qui vous permet de désactiver l'ajout de traits de soulignement aux noms de procédures internes. Si un nom de fichier est spécifié, cela est effectué uniquement pour les noms de procédures répertoriés dans le fichier spécifié.

Par défaut, en Fortran, les paramètres sont passés par référence, et en C, ils sont toujours passés par valeur. Ainsi, lors de l'appel d'une procédure Fortran depuis un module C, il faut passer des pointeurs vers les variables correspondantes contenant les valeurs des paramètres réels en tant que paramètres. Lors de l'écriture d'une fonction en C qui devra être appelée depuis un module Fortran, il faut décrire les paramètres formels comme des pointeurs vers les types correspondants.

Dans les modules C, il est possible d'utiliser des blocs COMMON définis à l'intérieur des modules Fortran (pour plus d'informations, voir le Guide de l'utilisateur du compilateur Intel Fortran, chapitre Mixage C et Fortran).

Partage des compilateurs Intel et GCC

Les modules objets C produits par le compilateur Intel C++ sont compatibles avec les modules produits par le compilateur GCC et la bibliothèque GNU C. Ainsi, ces modules peuvent être utilisés ensemble dans un seul programme compilé à l'aide des commandes icc ou gcc, mais il est recommandé d'utiliser icc pour inclure correctement les bibliothèques Intel.

Le compilateur Intel prend en charge un certain nombre d'extensions de langage C non standard utilisées par le projet GNU et prises en charge par le compilateur GCC (mais pas toutes, voir ici pour plus de détails).

Le manuel d'utilisation ne dit rien sur la compatibilité des modules objets dans les langages C++ et Fortran ; apparemment, il n'est pas supporté.

Prise en charge des normes

Le compilateur Intel C++ 7.0 pour Linux prend en charge la norme de langage ANSI/ISO C (ISO/IEC 9899/1990). Il est possible d'établir une compatibilité stricte avec la norme ANSI C ( -ansi) ou un dialecte ANSI C étendu ( -Xa). Lorsque vous utilisez l'option -c99

Dans le numéro précédent du magazine, nous avons discuté des produits de la famille Intel VTune Performance Analyser - des outils d'analyse des performances qui sont à juste titre populaires parmi les développeurs d'applications et permettent la détection dans le code. candidatures d'équipe, qui gaspillent trop de ressources CPU, donnant aux développeurs la possibilité d'identifier et d'éliminer les potentiels endroits étroits, associés à des sections de code similaires, accélérant ainsi le processus de développement d'applications. Notez cependant que les performances des applications dépendent en grande partie de l'efficacité des compilateurs utilisés dans leur développement et des fonctionnalités. matériel ils sont utilisés lors de la génération de code machine.

Les dernières versions des compilateurs Intel Intel C++ et Intel Fortran pour Windows et Linux vous permettent de bénéficier d'avantages en termes de performances applicatives pour les systèmes basés sur Processeurs Intel Itanium 2, Intel Xeon et Intel Pentium 4 jusqu'à 40 % par rapport aux compilateurs existants d'autres fabricants grâce à l'utilisation de fonctionnalités de ces processeurs telles que la technologie Hyper-Threading.

Les différences associées à l'optimisation du code par cette famille de compilateurs incluent l'utilisation d'une pile pour effectuer des opérations en virgule flottante, l'optimisation interprocédurale (IPO), l'optimisation conformément au profil d'application (Profile Guided Optimization (PGO), le préchargement des données dans le cache ( Data prefetching), qui évite la latence liée à l'accès à la mémoire, prise en charge des fonctionnalités caractéristiques des processeurs Intel (par exemple, extensions pour le traitement des données en streaming Intel Streaming SIMD Extensions 2, caractéristiques de l'Intel Pentium 4), parallélisation automatique de l'exécution du code, application création, fonctionnant sur plusieurs différents types processeurs lors de l'optimisation pour l'un d'entre eux, outils pour « prédire » le code ultérieur (prédiction de branche), prise en charge étendue du travail avec les threads d'exécution.

Notez que les compilateurs Intel sont utilisés dans des sociétés aussi connues que Alias/Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM. Selon des tests indépendants effectués par un certain nombre d'entreprises, les performances des compilateurs Intel sont nettement supérieures à celles des compilateurs d'autres fabricants (voir, par exemple, http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf .pdf).

Ci-dessous, nous examinerons quelques fonctionnalités dernières versions Compilateurs Intel pour ordinateur de bureau et serveur systèmes d'exploitation.

Compilateurs pour la plateforme Microsoft Windows

Compilateur Intel C++ 7.1 pour Windows

Intel C++ Compiler 7.1 est un compilateur publié plus tôt cette année qui fournit un code hautement optimisé pour les processeurs Intel Itanium, Intel Itanium 2, Intel Pentium 4 et Intel Xeon, ainsi que pour le processeur Intel Pentium M utilisant la technologie Intel Centrino et destiné à être utilisé dans appareils mobiles.

Le compilateur spécifié est entièrement compatible avec les outils de développement Microsoft Visual C++ 6.0 et Microsoft Visual Studio .NET : il peut être intégré aux environnements de développement correspondants.

Ce compilateur prend en charge les normes ANSI et ISO C/C++.

Compilateur Intel Fortran 7.1 pour Windows

Intel Fortran Compiler 7.1 pour Windows, également publié plus tôt cette année, vous permet de créer du code optimisé pour les processeurs Intel Itanium, Intel Itanium 2, Intel Pentium 4 et Intel Xeon, Intel Pentium M.

Ce compilateur est entièrement compatible avec les outils de développement Microsoft Visual C++ 6.0 et Microsoft Visual Studio .NET, c'est-à-dire qu'il peut être intégré aux environnements de développement correspondants. De plus, ce compilateur vous permet de développer des applications 64 bits pour les systèmes d'exploitation fonctionnant sur des processeurs Itanium/Itanium 2 à l'aide de Microsoft Visual Studio sur un processeur Pentium 32 bits à l'aide du compilateur Intel Fortran 64 bits. Lors du débogage du code, ce compilateur vous permet d'utiliser un débogueur pour Plateformes Microsoft.FILET.

Si le produit Compaq est installé, Visual Fortran 6.6 peut être utilisé à la place du compilateur Intel Fortran 7.1 d'origine, car ces compilateurs sont compatibles au niveau code source.

Intel Fortran Compiler 7.1 pour Windows est entièrement compatible avec la norme ISO Fortran 95 et prend en charge la création et le débogage d'applications contenant du code en deux langages : C et Fortran.

Compilateurs pour la plateforme Linux

Compilateur Intel C++ 7.1 pour Linux

Un autre compilateur sorti en début d'année, Intel C++ Compiler 7.1 pour Linux, permet d'atteindre un haut degré d'optimisation du code pour les processeurs Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Ce compilateur est entièrement compatible avec le compilateur GNU C au niveau du code source et des modules objets, ce qui vous permet d'y migrer sans frais supplémentaires des applications créées à l'aide de GNU C. Le compilateur Intel C++ prend en charge l'ABI C++ (un ajout au noyau Linux qui vous permet d'exécuter sous Contrôle Linux code compilé pour d'autres plates-formes telles que les premiers systèmes d'exploitation SCO, premières versions Sun Solaris, etc.), ce qui signifie une compatibilité totale avec le compilateur gcc 3.2 au niveau du code binaire. Enfin, avec Intel C++ Compiler 7.1 pour Linux, vous pouvez même recompiler le noyau Linux en apportant quelques modifications mineures à son code source.

Compilateur Intel Fortran 7.1 pour Linux

Intel Fortran Compiler 7.1 pour Linux vous permet de créer du code optimisé pour les processeurs Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Ce compilateur est entièrement compatible avec le compilateur Compaq Visual Fortran 6.6 au niveau du code source, vous permettant de recompiler les applications l'utilisant créées à l'aide de Compaq Visual Fortran, augmentant ainsi leurs performances.

De plus, le compilateur spécifié est compatible avec les utilitaires utilisés par les développeurs tels que l'éditeur emacs, le débogueur gdb et l'utilitaire de création d'application make.

Comme la version Windows de ce compilateur, Intel Fortran Compiler 7.1 pour Linux est entièrement compatible avec la norme ISO Fortran 95 et prend en charge la création et le débogage d'applications contenant du code en deux langages : C et Fortran.

Il convient de souligner en particulier qu'une contribution significative à la création des compilateurs Intel répertoriés a été apportée par des spécialistes du Centre de développement de logiciels Intel russe à Nijni Novgorod. Plus des informations détaillées Des informations sur les compilateurs Intel sont disponibles sur le site Web d'Intel à l'adresse www.intel.com/software/products/.

La deuxième partie de cet article sera consacrée aux compilateurs Intel qui créent des applications pour appareils mobiles.

Exemples de hacks réels : Compilateur Intel C++ 7.0 - Archive WASM.RU

...le compilateur Intel C++ 7.0 a été téléchargé tard dans la nuit, vers cinq heures du matin. J'avais très envie de dormir, mais j'étais aussi déchiré par la curiosité : si la protection avait été renforcée ou non. Décidant que tant que je n'aurais pas compris la protection, je ne m'endormirais toujours pas, j'ai ouvert nouvelle console, et la réinitialisation des variables système TEMP et TMP dans le répertoire C:\TEMP, tapées à la hâte de manière indécente nom long installateur W_CC_P_7.0.073.exe sur la ligne de commande (la nécessité de définir les variables TEMP et TMP s'explique par le fait que dans Windows 2000, elles pointent par défaut vers un répertoire très profondément imbriqué, et le programme d'installation Intel C++ - et pas seulement lui - ne prend pas en charge des chemins d'une telle taille).

Il est immédiatement devenu évident que la politique de protection avait été radicalement révisée et que désormais la présence d'une licence était déjà vérifiée au stade de l'installation du programme (dans la version 5.x, l'installation s'est effectuée sans problème). OK, nous donnons la commande dir et regardons le contenu de ce avec quoi nous devons maintenant nous battre :

Contenu du dossier C:\TMP\IntelC++Compiler70

17.03.2003 05:10

HTML

17.03.2003 05:11

x86

17.03.2003 05:11

Itanium

17.03.2003 05:11

Remarques

05/06/2002 10:35 45 056 AutoRun.exe

10/07/2001 12:56 27 autorun.inf

29.10.2002 11:25 2 831 ccompindex.htm

24/10/2002 08:12 126 976 ChkLic.dll

18/10/2002 22:37 552 960 chklic.exe

17/10/2002 16:29 28 663 CLicense.rtf

17.10.2002 16:35 386 credit.txt

16.10.2002 17:02 34 136 Crellnotes.htm

19/03/2002 14:28 4 635 PLSuite.htm

21/02/2002 12:39 2 478 registre.htm

02.10.2002 14:51 40 960 Setup.exe

02.10.2002 10:40 151 Setup.ini

10/07/2001 12:56 184 setup.mwg

19 fichiers 2 519 238 octets

6 dossiers 886 571 008 octets libres

Ouais! Le programme d'installation setup.exe ne prend qu'une quarantaine de kilo-octets. Très bien! Il est peu probable que vous puissiez cacher une protection sérieuse dans un tel volume, et même si c'est le cas, ce petit fichier ne vaut rien à analyser dans son intégralité - jusqu'au dernier octet de la liste du désassembleur. Cependant, ce n'est pas un fait que code de sécurité situé exactement dans setup.exe, il peut être situé à un autre endroit, par exemple... ChkLic.dll/ChkLic.exe, qui occupent ensemble un peu moins de sept cents kilo-octets. Attendez, qu'est-ce que ChkLic ? C'est l'abréviation de Check License ou quoi ?! Hmm, les gars d'Intel ont évidemment de sérieux problèmes avec le sens de l'humour. Ce serait mieux s'ils appelaient ce fichier "Hack Me" honnêtement ! D'accord, à en juger par le volume, ChkLic est le même FLEX lm, et nous l'avons déjà rencontré (voir "Compilateur Intel C++ 5.0") et avons une idée générale de la façon de le casser.

On donne la commande « dumpbin /EXPORTS ChkLic.dll » pour examiner les fonctions exportées et... on s'accroche fermement à Klava pour ne pas tomber de la chaise :

Dump du fichier ChkLic.dll

1. La section contient les exportations suivantes pour ChkLic.dll

   0 caractéristiques

   3DB438B4 horodatage lundi 21 octobre 21:26:12 2002

3. 1 nombre de fonctions

   1 nombre de noms

   indice ordinal nom RVA

   1 0 000010A0 _CheckValidLicense

Bon sang! La protection n'exporte qu'une seule fonction sous le merveilleux nom CheckValidLicense. "Merveilleux" - parce que le but de la fonction ressort clairement de son nom et qu'il devient possible d'éviter une analyse minutieuse du code du désassembleur. Eh bien, ils ont perdu tout intérêt... ce serait mieux s'ils l'exportaient de manière ordinaire ou quelque chose du genre, ou du moins le baptisaient avec une sorte de nom intimidant comme DES Decrypt.

...en rêvant ! Bon, revenons à nos moutons. Pensons logiquement : si tout le code de sécurité est concentré directement dans ChkLic.dll (et, à en juger par la nature « articulée » de la protection, c'est bien le cas), alors toute « protection » se résume à appeler CheckValidLicense depuis le programme d'installation. exe et en vérifiant le résultat renvoyé par celui-ci. Par conséquent, pour « pirater », il suffit de perdre ChkLic.dll, forçant la fonction ChekValidLicense à toujours revenir... et, au fait, que doit-elle retourner ? Plus précisément : quelle est exactement la valeur de retour qui correspond à un contrôle de licence réussi ? Non, ne vous précipitez pas pour démonter setup.exe pour le déterminer, car options possibles plus tellement : soit FAUX, soit VRAI. Pariez-vous sur VRAI ? Eh bien, dans un sens, c'est logique, mais d'un autre côté : pourquoi avons-nous réellement décidé que la fonction CheckValidLicense renvoie exactement le drapeau du succès de l'opération, et non le code d'erreur ? Après tout, cela doit en quelque sorte motiver les raisons du refus d'installer le compilateur : le fichier avec la licence n'a pas été trouvé, le fichier est endommagé, la licence a expiré, et ainsi de suite ? D'accord, essayons de renvoyer zéro, et si cela ne fonctionne pas, nous en renverrons un.

OK, attachez votre ceinture, c'est parti ! Nous lançons HIEW, ouvrons le fichier ChkLic.dll (s'il ne s'ouvre pas, rappelez-vous les gophers trois fois, copiez-le temporairement à la racine ou dans tout autre répertoire qui ne contient pas de caractères spéciaux dans son nom que hiew n'aime pas) Ensuite, en revenant à la table d'exportation obtenue avec dumpbin, nous déterminons l'adresse de la fonction CheckValidLicense (dans ce cas 010A0h) et par « 10A0 » nous revenons à son début. Maintenant, nous la coupons « live », en écrasant le ancien code « XOR EAX, EAX/RETN 4 ». Pourquoi exactement « REN 4 » et pas seulement « RET » ? Oui, car la fonction supporte la convention stdcall, que vous pouvez découvrir en regardant son épilogue dans HIEW"e ( faites simplement défiler l'écran du désassembleur jusqu'à rencontrer RET).

Vérifions... Ça marche !!! Malgré l'absence de licence, l'installateur démarre l'installation sans se poser de questions ! La défense est donc tombée. Oh, nous ne pouvons pas croire que tout soit si simple et, afin de ne pas rester bêtement assis à regarder le moniteur en attendant la fin du processus d'installation du programme, nous utilisons notre désassembleur IDA préféré sur setup.exe. La première chose qui frappe est l’absence de CheckValidLicense dans la liste des fonctions importées. Peut-être qu'il lance d'une manière ou d'une autre le fichier ChkLic.exe ? On essaie de trouver le lien correspondant parmi les lignes automatiquement reconnues : « ~View aNames », « ChkLic »... ouais, la ligne « Chklic.exe » n'est pas là du tout, mais « Chklic.dll » est détecté. Ouais, je vois, cela signifie que la bibliothèque ChkLic est chargée par liaison explicite via LoadLibrary. Et suivre la référence croisée confirme ceci :

Texte : 0040175D décalage de poussée aChklic_dll ; lpLibFileName

Texte : 00401762, appelez ds : LoadLibraryA

Texte :00401762 ; charger ChkLic.dll ^^^^^^^^^^^^^^^^^

Texte :00401762 ;

Texte : 00401768 mov esi, eax

Text:0040176A push offset a_checkvalidlic ; lpProcName

Texte : 0040176F pousser esi ; hModule

Texte : 00401770, appel ds : GetProcAddress

Texte :00401770 ; obtenir l'adresse de la fonction CheckValidLicense

Texte :00401770 ;

Texte : 00401776 cmp esi, ebx

Texte : 00401778 jz loc_40192E

Texte : 00401778 ; s'il n'existe pas de bibliothèque de ce type, quittez le programme d'installation

Texte : 00401778 ;

Texte : 0040177E cmp eax, ebx

Texte : 00401780 jz loc_40192E

Texte : 00401780 ; s'il n'y a pas de telle fonction dans la bibliothèque, quittez l'installation

Texte : 00401780 ;

Texte : 00401786 pousser ebx

Texte : 00401787, appelez eax

Texte : 00401787 ; appeler la fonction ChekValidLicense

Texte : 00401787 ;

Texte : 00401789 test eax, eax

Texte : 0040178B jnz loc_4019A3

Texte :0040178 ; si la fonction renvoie une valeur différente de zéro, quittez le programme d'installation

Incroyablement, cette défense terriblement primitive est construite exactement comme ça ! De plus, le fichier d'un demi-mètre ChkLic.exe n'est pas du tout nécessaire ! Et pourquoi cela valait-il la peine de le retirer d’Internet ? D'ailleurs, si vous décidez de sauvegarder la distribution du compilateur (attention : je n'ai pas dit « distribuer » !), alors pour gagner de la place disque, ChkLic.* peut être effacé : soit en supprimant setup.exe, en le sevrant définitivement de en y accédant, ou en créant simplement votre propre ChkLic.dll, en exportant la fonction stdcall CheckValidLicence de la forme : int CheckValidLicence(int some_flag) ( return 0 ;)

Eh bien, pendant que nous discutions de tout cela, le programme d'installation a terminé l'installation du compilateur et a terminé son travail avec succès. Est-il intéressant de savoir si le compilateur va démarrer ou si tout le plaisir ne fait que commencer ? On parcourt fébrilement la hiérarchie ramifiée des sous-dossiers, on trouve icl.exe qui, comme on pouvait s'y attendre, se trouve dans le répertoire bin, on clique et... Le compilateur ne démarre naturellement pas, invoquant le fait que "icl: erreur : "Je n'ai pas pu récupérer la licence FLEX lm", sans laquelle il ne peut pas continuer son travail.

Il s’avère qu’Intel a utilisé une protection à plusieurs niveaux et que le premier niveau s’est avéré être une protection rudimentaire contre les imbéciles. Bien! Nous acceptons ce défi et, sur la base de notre expérience précédente, recherchons automatiquement le fichier LMGR*.DLL dans le répertoire du compilateur. Inutile! Cette fois, il n'y a pas de fichier de ce type ici, mais il s'avère que icl.exe a pris beaucoup de poids, dépassant la barre des six cents kilo-octets... Stop ! Les développeurs du compilateur n'ont-ils pas lié ce même FLEX lm avec une liaison statique ? Voyons voir : dans Intel C++ 5.0, la somme des tailles de lmgr327.dll et icl.exe était de 598 Ko, et maintenant icl.exe occupe à lui seul 684 Ko. En tenant compte de l’ajustement pour « l’obésité » naturelle sénile, les chiffres concordent très bien. Alors, après tout, FLEX lm ! Ah oh ! Mais désormais, sans noms de fonctions symboliques, il sera bien plus difficile de briser la protection... Mais ne paniquez pas d'avance ! Réfléchissons, calmement ! Il est peu probable que l’équipe de développement ait complètement réécrit tout le code qui interagit avec cette protection « enveloppe ». Très probablement, son « amélioration » s'est terminée par un simple changement dans le type de mise en page. Et si c'est le cas, alors les chances de pirater le programme sont toujours grandes !

En nous rappelant que la dernière fois que le code de sécurité était dans la fonction principale, nous, après avoir déterminé son adresse, avons simplement défini un point d'arrêt et, en attendant que le débogueur apparaisse, traçons bêtement le code, en regardant alternativement le débogueur, puis la sortie du programme fenêtre : est-elle apparue ? Y a-t-il un message injurieux ? En même temps, nous marquons toutes les transitions conditionnelles que nous rencontrons sur une feuille de papier séparée (ou la mettons dans notre propre mémoire, si vous le souhaitez), sans oublier d'indiquer si chaque transition conditionnelle a été effectuée ou non... Stop ! Toi et moi discutions de quelque chose, mais un message abusif est déjà apparu ! OK bien! Voyons à quelle transition conditionnelle cela correspond. Nos enregistrements montrent que le dernier saut rencontré était le saut conditionnel JNZ, situé à l'adresse 0401075h et "réagissant" au résultat renvoyé par sub_404C0E :

Texte : 0040107F loc_40107F : ; CODE XREF : _main+75^j

Text:0040107F mov eax, décalage aFfrps ; "FFrps"

Text:00401084 mov edx, 21h

Texte : 00401089, appel sub_404C0E

Texte : 0040108E test eax, eax

Texte : 00401090 jnz court loc_40109A

Évidemment, sub_404C0E est la procédure très protectrice qui vérifie la présence de la licence. Comment la tromper ? Eh bien, il existe de nombreuses options... Tout d'abord, vous pouvez analyser de manière réfléchie et scrupuleusement le contenu de sub_404C0E pour savoir exactement ce qu'il vérifie et comment il vérifie exactement. Deuxièmement, vous pouvez simplement remplacer JNZ short loc_40107F par JZ short loc_40107F ou même NOP, NOP. Troisièmement, la commande de vérification du résultat renvoyé TEST EAX, EAX peut être transformée en une commande nulle : XOR EAX, EAX. Quatrièmement, vous pouvez faire disparaître sub_404C0E lui-même afin qu'il renvoie toujours zéro. Je ne sais pas pour vous, mais j’ai le plus aimé la méthode numéro trois. Nous modifions deux octets et lançons le compilateur. S'il n'y a pas d'autres contrôles de sa « licence » dans la protection, alors le programme fonctionnera et, par conséquent, vice versa. (Comme nous nous en souvenons, dans la cinquième version, il y avait deux contrôles de ce type). Étonnamment, le compilateur ne se plaint plus et fonctionne !!! En effet, comme on pouvait s'y attendre, ses développeurs n'ont pas du tout renforcé la protection, mais au contraire l'ont même affaiblie ! Chris Kaspersky

Vous n'êtes pas un esclave !
Cours pédagogique fermé pour les enfants des élites : « Le véritable arrangement du monde ».
http://noslave.org

Matériel de Wikipédia - l'encyclopédie gratuite