Windows Embedded CE 6.0 et la sécurité

  • Article

Cet article a été écrit par Olivier Bloch, Responsable Relations Techniques avec les Développeurs.

Windows Embedded CE 6.0 est un système d'exploitation modulaire 32 bits temps réel supportant de multiples architectures CPUs (ARM, MIPS, SH, x86). Il est conçu pour être adapté et embarqué dans des systèmes parfois critiques, souvent interactifs, mais nécessitant le plus souvent un niveau de sécurité et de fiabilité très élevé.

Cet article décrit les principaux éléments qui font de la version 6.0 de Windows CE la version la plus sécurisée. Présentant les nouveautés apportées à la gestion de la mémoire virtuelle et à l'architecture du noyau, il détaille les modes User et Kernel pour les applications et les drivers avant d'introduire le nouveau modèle de sécurité 1-Tiers de Windows Embedded CE 6.0. Il présente enfin les outils mis à disposition du développeur afin de lui permettre le développement d'applications et de drivers toujours plus sécurisés.

Sommaire

Nouvelle architecture du noyau : séparation des modes User et Kernel

  • Architecture mémoire de CE 6
  • Architecture du Système
  • Le mode Kernel
  • Callbacks

Les drivers : Le User Mode Driver Framework

Protection du système au chargement et à l'exécution de code

  • Avant Windows Embedded CE 6.0
  • Avec Windows Embedded CE 6.0
  • Cas 1 : terminal fermé
  • Cas 2 : terminal semi-fermé
  • Cas 3 : terminal ouvert

Outils, compilateurs et runtimes

  • Options de compilation et d'édition de lien
  • Security-enhanced CRT
  • Safe String Functions
  • Analyse du code C/C++
  • Application Verifier

Conclusion

Nouvelle architecture du noyau : séparation des modes User et Kernel

L'architecture de la gestion de la mémoire virtuelle et celle du système ont été repensées et modifiées. Supprimant les limites des versions précédentes, la gestion de la mémoire virtuelle de Windows Embedded CE 6.0 permet la cohabitation de 32768 processus, disposant chacun de 2Go de mémoire virtuelle (les limites étaient précédemment de 32 processus avec 32 Mo de mémoire virtuelle par processus).

De plus l'architecture du noyau a elle aussi été modifiée afin d'unifier le noyau et d'améliorer les performances générales du système.

Ces modifications n'ont pas été faites au détriment de la sécurité du système, bien au contraire.

Architecture mémoire de CE 6

Les 4Go de mémoire virtuelle sont partagés comme ceci :

Toutes les applications sont chargées et accèdent aux 2 Go inférieurs de la mémoire virtuelle. Tout accès à la partie supérieure, celle dans laquelle est chargé le Kernel et qu'il utilise, se fait via un appel à une API (Application Programming Interface) du système (accéder à un driver via le Device Manager, accéder au File System, etc. ?). Ainsi, aucun accès à des ressources critiques (système ou hardware) ne peut se faire sans la vérification et le contrôle du système.

Architecture du Système

L'architecture du noyau de Windows Embedded CE 6.0 a été repensée et modifiée. Elle se présente désormais comme ceci :

Alors que dans les versions précédentes de Windows CE les services du noyau tels que le Device Manager, ou le File System ou bien encore GWES (Graphical Windowing and Event Subsystem) étaient des processus séparés du Kernel, ils se présentent désormais sous la forme de DLLs qui sont chargées par le processus Kernel.

Ceci a pour premier impact de réduire l'overhead sur les appels systèmes. En effet, alors que dans les versions antérieures à Windows Embedded CE 6.0 un appel à un service du système depuis une application (driver par exemple) devait transiter par plusieurs processus (filesys.exe, nk.exe, device.exe pour l'exemple de l'appel à un driver), le même appel ne transitera plus que par le processus du Kernel. Cela permet aussi de cloisonner le Kernel en ne permettant pas aux applications et certains drivers d'accéder aux ressources système et hardware sans passer par un appel système.

En ce qui concerne les drivers, il est possible de choisir s'ils seront chargés dans l'espace Kernel ou dans l'espace User. En effet, on voudra pour certains drivers dont on connait la robustesse, pouvoir les charger en mode Kernel et ainsi leur permettre un fonctionnement plus performant. Dans ce cas, ils pourront librement accéder aux ressources hardware. Mais pour d'autres drivers (tierce partie, installables ou moins robustes), on voudra s'assurer qu'ils ne peuvent nuire au fonctionnement général du système, et on les chargera dans un (ou plusieurs) processus en mode User. Ces drivers pourront accéder aux ressources critiques, mais toujours sous le contrôle du système, et ceci à l'aide du "User Mode Driver Framework" (cfr. Chapitre suivant).

Le mode Kernel

  • Dans Windows CE 5.0 et les versions précédentes, le mode "Kernel" est un niveau d'accès rattaché à un thread. Lorsqu'un thread est en mode Kernel, il peut accéder à l'espace mémoire Kernel. On peut appeler l'API SetKMode pour changer le mode d'un thread. La plupart des APIs du système ne sont pas implémentées par le Kernel (nk.exe), ainsi, appeler une de ces API ne met pas le thread dans le mode Kernel pour autant, tandis que l'appel à une API implémentée dans le Kernel, met temporairement le thread en mode Kernel pendant la durée de l'appel.
  • Dans Windows Embedded CE 6.0, l'implémentation est la même, si ce n'est que l'API SetKMode n'est plus supportée. On ne peut plus mettre un thread en mode Kernel lorsqu'on le désire. Toutefois, la plupart des APIs système étant désormais implémentées dans des modules désormais chargés dans le contexte du process Kernel, l'appel à l'une de ces API met le thread en mode Kernel pendant la durée de l'appel de fait.

Alors que l'implémentation est la même, le résultat diffère. Dans CE 5.0, le mode Kernel est une propriété qu'un thread peut acquérir ou perdre à la demande. Dans CE 6.0, la règle est très simple : le thread est en mode Kernel lorsqu'il exécute du code dans le contexte du process Kernel, et en mode User lorsqu'il s'éxécute dans le contexte d'un process User.

Note : Le terme "Kernel" est couramment utilisé pour décrire du code et des adresses uniquement accessibles au processus Kernel (adresses supérieures à 0x80000000) : drivers en mode Kernel, code en mode Kernel, addresses en mode Kernel.

Callbacks

Des précautions particulières sont à prendre dans Windows Embedded CE 6.0 au sujet des callbacks. Lorsqu'une application passe un pointeur de fonction en paramètre à du code en mode Kernel (driver en mode Kernel par exemple) afin d'être notifié en retour, le code de la fonction de notification s'exécute dans le contexte d'un thread qui est en mode Kernel. Ceci présente une faille de sécurité importante dans la mesure où le code User de la fonction de callback pourrait alors accéder à des adresses en mode Kernel ou appeler des APIs "Kernel-only".

Lorsqu'on écrit un driver qui implémente ce mécanisme de callback, il faut s'assurer de la bonne utilisation de la fonction du CEDDK (CE Driver Development Kit) CeDriverPerformCallback qui garantira le passage du thread en mode User avant l'appel de la fonction de callback empêchant ainsi à ce code originellement en mode User d'accéder à des ressources critiques.

Attention, la terminologie "Kernel Mode" utilisée ici n'a aucune relation avec son utilisation pour décrire le mode d'un CPU exécutant des instructions particulières non utilisables en temps normal (gestion des interruptions par exemple). Lorsqu'un thread Windows CE est en mode Kernel, cela ne signifie pas qu'il sera en mesure d'utiliser ce mode CPU particulier. Il n'y a que quelques parties du Kernel et de l'OAL qui exploitent ce mode privilégié du CPU.

Les drivers : Le User Mode Driver Framework

Comme évoqué dans les chapitres précédents, la nouvelle architecture du noyau de Windows Embedded CE 6.0 propose deux modes d'éxécution : le mode User et le mode Kernel. Ceci concerne aussi les drivers qui pourront s'exécuter dans un mode ou un l'autre. Chargé en mode Kernel par le module Device Manager du Kernel, un driver pourra accéder de manière optimale (en terme de performance) aux ressources système et hardware, tandis que chargé en mode User, un driver ne pourra nuire à la robustesse du système. Afin de permettre cela, Windows Embedded CE 6.0 propose Le User Mode Driver Framework.

Le User Mode Driver Framework se présente sous la forme de deux composants physiques :

  • Le User Mode Driver Reflector, qui réside dans le contexte du module Device Manager du Kernel.
  • Le User Mode Driver Host, qui est une application en mode User lancée et gérée par le User Mode Driver Reflector.

Lorsqu'un driver est désigné comme étant un driver en mode User dans le registre, le Device Manager passera par le User Mode Driver Reflector. Celui-ci lance le processus User Mode Host adéquate vers lequel il redirige les appels. Le processus User Mode Driver Host redirige à son tour les appels vers le driver en mode User :

Le mécanisme d'utilisation d'un driver en mode User est initié par une application en mode User ou un driver de "Parent Bus" qui peuvent charger les drivers en mode User en appelant ActivateDevice ou ActivateDeviceEx et les décharger en appelant DeactivateDevice. Une fois un driver en mode User chargé, une application en mode User ou un driver peuvent y accéder en utilisant son Device Handle.

Lorsqu'un driver est en mode User, l'appel à ActivateDevice ou ActivateDeviceEx est aussi redirigé vers le User Mode Driver Reflector. Un driver est configuré comme étant en mode User lorsque dans la clé de base de registre du driver la valeur FLAGS est positionnée à DEVFLAGS_LOAD_AS_USERPROC (0x10).

Le User Mode Driver Reflector, qui connait les processus d'origine et de destination, utilise CeFsIoControl pour rediriger les appels du Device Manager vers le User Mode Driver Host. Le User Mode Driver Host va ensuite charger, décharger, appeler les fonctions du driver en mode User, ou bien encore appeler l'entrée du Parent Bus.

Le driver en mode User a des droits d'accès au hardware qui sont donc restreints, ce qui l'empêche d'utiliser des fonctionnalités telles que le mapping de mémoire physique ou l'appel aux fonctions de gestion d'interruption. Pour accomplir ce type d'opérations, le driver en mode User appelle le User Mode Driver Reflector à qui il confie la gestion de ces opérations. Le User Mode Driver Reflector vérifie alors en fonction des paramètres de base de registre s'il peut ou non répondre à cette requête. En revanche, l'accès au driver du Parent Bus n'est pas restreint pour le driver en mode User, et ceci quelque soit le mode dudit driver et sans l'intervention du User Mode Driver Reflector.

Protection du système au chargement et à l'exécution de code

Avant Windows Embedded CE 6.0

Dans les versions antérieures à 6.0 de Windows CE, il est possible d'activer un modèle de sécurité reposant essentiellement sur l'utilisation des certificats. Chaque module (dll ou exe) est signé avec un certificat et appartient alors à l'une de ces catégories:

  • "Full Trust" : c'est typiquement le cas de dll/exe signés avec un certificat enregistré sur le système. Dans ce cas, le module est autorisé au chargement et le code peut appeler toutes les API du système.
  • "Run" : c'est le cas des modules signés avec un certificat enregistré sur le système avec un niveau de confiance moindre. Dans ce cas, le module est chargé mais certaines APIs du système lui sont interdites (SetKMode par exemple).
  • "Untrusted" : c'est le cas des modules non signés ou signés avec un certificat non enregistré/reconnu sur le système et qui ne peuvent donc être chargé sur le système.

On peut aussi envisager de ne pas implémenter ce mécanisme et de limiter les appels aux APIs système à toutes les applications qui ne sont pas en ROM (qui n'ont pas été intégrées dès le départ au noyau).

Avec Windows Embedded CE 6.0

Désormais sous Windows Embedded CE 6.0, le modèle proposé est de type 1-Tiers. Le mécanisme se présente en deux parties "API Privilege" et "Load Privilege" :

  • "API Privilege" : permet d'autoriser (ou non) le code d'un module à accéder à certaines APIs marquées comme n'étant accessibles qu'aux modules en mode Kernel. Cette vérification repose sur l'adresse à laquelle est chargé le code du module : s'il est chargé à une adresse supérieure à 0x80000000, il est considéré comme étant en mode Kernel et pourra accéder à ces APIs protégées, s'il est chargé à une adresse inférieure, il sera considéré comme étant en mode User et ne pourra accéder à ces APIs. Ainsi ce mécanisme est indépendant du certificat associé au module concerné.
  • "Load Privilege" : le système autorise ou non le chargement d'un module (par exemple, lorsqu'une application appelle CreateProcess ou LoadLibrary). Ce mécanisme est mis en ?uvre lorsque le composant de gestion de la certification est inclus dans le noyau (cf. plus loin). Il répond aux règles suivantes :
    • - Tout module dont le fichier a l'attribut ROM est "Fully Trusted".
    • - Tout module signé avec un certificat enregistré sur le système est "Fully Trusted".
    • - Tous les autres modules sont "Untrusted".

En prenant en considération tout ceci, voici les différentes possibilités pour la création d'un système Windows Embedded CE 6.0 :

Cas 1 : terminal fermé

L'OEM veut développer un terminal fermé, il doit :

  • Activer la variable d'environnement SYSGEN_CERTMOD pour la génération du noyau
  • Ne pas charger de certificats sur le terminal
  • S'assurer que tous les modules qui doivent tourner sur le terminal sont bien en ROM

Une fois un noyau généré avec de tels paramètres, aucune application ou module tierce partie ne pourra être chargé sur ce système.

Cas 2 : terminal semi-fermé

L'OEM veut développer un terminal semi-fermé sur lequel seulement les modules signés pourront être chargés par le système, il doit alors :

  • Activer la variable d'environnement SYSGEN_CERTMOD pour la génération du noyau
  • Ajouter un ou plusieurs certificats sur le terminal
  • S'assurer que tous les modules qui doivent tourner sur le terminal sont soit en ROM, soit signés avec un certificat chargé sur le terminal.

Cette solution est la bonne si l'OEM veut publier un SDK pour ses terminaux, permettant ainsi à ces éditeurs de logiciel d'écrire des applications pour leur plateforme. En imposant la signature des applications avec leur certificat, les OEM peuvent contrôler quelles applications sont ou non autorisées à s'exécuter sur le terminal.

Cas 3 : terminal ouvert

L'OEM veut développer un terminal totalement ouvert, il doit :

  • désactiver la variable d'environnement SYSGEN_CERTMOD pour la génération du noyau

Dans ce cas, tous les modules du système sont considérés comme étant "Fully Trusted" et toute tentative de chargement aboutira. Notez que SYSGEN_CERTMOD ne fait que gérer les privilèges de chargement. Une fois le module chargé, les APIs auxquelles il a accès dépendent du mode d'exécution (User ou Kernel) des threads du module, et cela dépend de l'espace mémoire dans lequel le module est chargé (cf. chapitres précédents).

Outils, compilateurs et runtimes

Nous venons de décrire dans les chapitres précédents les éléments qui font de Windows Embedded CE 6.0 la version du système la plus sécurisée. Toutefois, il est indispensable que les développeurs système et d'applications mettent en ?uvre tous ces mécanismes et utilisent les outils, compilateurs et runtimes au mieux afin de construire un système embarqué réellement sécurisé et robuste.

En effet lorsqu'une application ou un driver sont considérés comme étant fiables et robustes, et qu'ils sont soit signés numériquement, soit inclus dans la ROM, ils peuvent, s'ils présentent des failles de sécurité, nuire à la robustesse de l'ensemble du système.

Lors de la génération de l'OS, le développeur pourra décider du type de modèle de sécurité général en implémentant ou non les fonctionnalités que nous avons cité précédemment : plateforme ouverte, semi ouverte ou fermée, drivers en mode Kernel ou User, signatures numériques, inclusion des applications dans la ROM? Il devra aussi suivre les recommandations sur l'usage de composants tels que "NDIS User-Mode I/O Protocol Driver" ou "Internet Connexion Sharing" qui par essence peuvent mettre le système en danger s'ils ne sont pas utilisés correctement. L'outil Platform Builder va indiquer au développeur les risques et les bonnes pratiques pour les éviter.

Lors du développement d'applications et de drivers, le développeur pourra s'appuyer sur divers outils mis à disposition dans Visual Studio pour rendre son code fiable et robuste, tels que les options de compilations et d'édition de lien, SafeSEH, l'analyse de code C/C++ ou bien encore la possibilité d'utiliser un Runtime C sécurisé.

Options de compilation et d'édition de lien

/GS :

Lorsque l'on compile avec l'option /GS active, le compilateur détecte les "Buffer Overruns" potentiels dans le code. Les situations de Buffer Overrun (comme celle de l'exemple ci-dessous) peuvent être exploitées, particulièrement sur des microprocesseurs tels que les x86 qui dans les conventions d'appel passent l'adresse de retour des appels de fonction à la fin de la pile : le code pouvant, à cause du Buffer Overrun, écraser et modifier cette adresse de retour et ainsi forcer l'exécution de code malicieux.

The following sample overruns a buffer. When built with /GS, this sample displays a message box, and then terminates the process.

#include <cstring>
// Vulnerable function

void vulnerable(const char *str)
{
   char buffer[10];
   strcpy(buffer, str); // overrun buffer !!!
}

int main()
{
   // declare buffer that is bigger than expected
   char large_buffer[] = "This string is longer than 10 characters!!!";
   vulnerable(large_buffer);

}

Afin d'éviter l'exploitation des situations de Buffer Overrun, lorsque du code est compilé avec l'option /GS, le compilateur identifie les fonctions qui sont sujettes à cette situation, il insert un identifiant de sécurité dans la pile avant l'adresse de retour. Si, à la sortie de la fonction l'identifiant de sécurité a changé, le compilateur signale une erreur et stoppe le processus.

Afin de permettre à /GS de protéger efficacement le code contre d'éventuelles attaques, la librairie C Runtime (CRT) doit être initialisée au lancement de l'application. Pour faire cela, il s'agit de configurer le point d'entrée comme étant une des routines de démarrage de la CRT. Si l'on ne fait pas cela, il faut appeler la fonction __security_init_cookie dès que possible dans l'exécution du code, avant qu'une quelconque fonction contenant la gestion d'un buffer ou d'exceptions soit ajoutée à la pile d'appels.

L'option /GS ne protège pas de toutes les attaques de type buffer overrun. Par exemple, les attaques sont toujours possibles en écrasant la zone des paramètres. Il faut donc, même si on utilise /GS, s'assurer que le code ne permette aucun buffer overrun.

SafeSEH :

Lorsque /SAFESEH est spécifié, l'éditeur de liens produit uniquement une image s'il peut également produire une table des gestionnaires d'exceptions sécurisés de l'image. Cette table indique au système d'exploitation les gestionnaires d'exceptions valides pour l'image.

/SAFESEH n'est valide que pour les cibles x86. Cette option n'est pas supportée sur les autres plateformes telles que ARM, MIPS ou SH, dans la mesure où ces plateformes positionnent les gestionnaires d'exceptions dans les structures PDATA.

Lorsque /SAFESEH:NO est spécifié, l'éditeur de liens ne produit pas d'image avec une table de gestionnaires d'exceptions sécurisés même si tous les modules sont compatibles avec la gestion sécurisée des exceptions.

Le système de génération d'OS s'appuie sur la variable d'environnement SAFESEH dans les fichiers SOURCES : "SAFESEH=1" pour activer SAFESEH et "SAFESEH=" pour désactiver l'option.

Security-enhanced CRT

Pour Windows Embedded CE 6.0 et les versions qui suivent, la librairie C Runtime (CRT) s'est vue ajouter les versions sécurisées des fonctions présentant des failles de sécurité. Les anciennes versions de ces fonctions sont désormais dépréciées et leur utilisation dans le code génère des warnings lors de la compilation.

Il est vivement recommandé d'utiliser les versions sécurisées de ces fonctions plutôt que de supprimer les warnings de compilation.

La librairie C Runtime (CRT) est un ensemble d'APIs définis dans le "C Programming Language with Extensions" de Microsoft il y a entre 10 et 30 ans. Depuis, beaucoup de lacunes et de failles d'architecture ont été identifiées et de nombreuses fonctions sont désormais disponibles en version sécurisées. Lorsqu'une nouvelle version sécurisée existe, l'ancienne version est indiquée comme dépréciée et la nouvelle se présente avec un suffixe _s.

NB : lorsqu'on l'on dit qu'une fonction est "dépréciée", cela signifie que son utilisation n'est pas recommandée.

Les versions sécurisées de ces fonctions permettent d'intercepter les erreurs, et effectuent des vérifications supplémentaires levant une exception lors de la détection d'une erreur.

Par exemple, la fonction strcpy ne peut pas savoir si la chaine de caractère qu'elle copie est ou non trop grande pour le buffer de destination. Sa version sécurisée strcpy_s, prend la taille du buffer en paramètre et peut donc déterminer si on est dans une situation de Buffer Overrun.

Lorsque des warnings signalent l'utilisation de fonctions dépréciées, il y a plusieurs solutions :

  • Désactiver ces warnings en définissant _CRT_SECURE_NO_DEPRECATE ou en utilisant le pragma warning. Attention, en faisant cela, le risque n'est pas évité.
  • Utiliser les versions sécurisées des fonctions signalées.
  • Définir _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES à 1. Ceci supprimera les warnings et changera tous les appels en leur version sécurisée. Pour plus d'information, voir la documentation de Visual Studio 2005.

Les améliorations en termes de sécurité couvrent entre autre :

  • Validation des paramètres : les paramètres passés aux fonctions CRT sont validées (vérification des valeurs NULL passées aux fonctions, validation des valeurs énumérées, vérification des bornes pour les entiers?)
  • Gestion de paramètre invalide : le développeur a à sa disposition un gestionnaire de paramètre invalide lui permettant de ne plus simplement voir son application se terminer, mais de prendre la main sur le problème en utilisant la fonction _set_invalid_parameter_handler et en connectant une fonction de callback.
  • Buffers de taille explicite : les fonctions sécurisées imposent l'ajout en paramètre de la taille du buffer en plus de son pointeur.
    • - Elles vérifient que le buffer est suffisamment grand pour pouvoir écrire dedans, permettant ainsi d'éviter les situations de Buffer Overrun évoquées plus haut.
    • - Elles retourneront code d'erreur de type errno et appelleront le gestionnaire de paramètre invalide si le buffer n'est pas de taille suffisante.
    • - Les fonctions qui lisent des données depuis un buffer, tel que des gets, ont des versions sécurisées qui imposent la spécification d'une taille maximum.
  • Terminaison des chaines de caractère : certaines fonctions qui potentiellement laissaient des chaines de caractère sans caractère de fin sont désormais disponibles dans une version sécurisée assurant la terminaison par un caractère nul.
  • Amélioration du rapport d'erreur : les fonctions sécurisées retournent des codes contenant plus d'information que leurs versions non sécurisées. Elles positionnent désormais errno et renvoient aussi souvent un code d'erreur de type errno.
  • Sécurité du système de fichier : par défaut, les APIs d'entrée sortie de fichier supportent l'accès sécurisé aux fichiers.
  • Vérification de la syntaxe des "format strings" : les strings invalides sont désormais détectés, comme par exemple, l'utilisation d'un mauvais descripteur de type de caractère dans un "format string" passé à la fonction printf.
  • D'autres améliorations sont décrites pour chaque fonction dans la documentation.

Fonctions "Safe String"

En plus des fonctions sécurisées de la CRT, Windows Embedded CE dispose de fonctions de gestion des chaînes de caractère améliorées en remplacement ou en complément des fonctions de la CRT servant à manipuler des chaînes de caractère. Les fonctions standard de manipulation de chaînes de caractère mal utilisées peuvent induire des problèmes de sécurité importants tels que Buffer Overrun ou bien encore l'injection de code malicieux. Les fonctions en questions sont disponibles via strsafe.h. Pour plus d'information, voir ici.

Analyse du code C/C++

L'outils d'analyse de code C/C++, PREFast, intercepte le compilateur natif et effectue une analyse statique inter-procédurale des fichiers source.

L'outil peur identifier les situations de Buffer Overrun, les problèmes de sémantique dans l'utilisation de HRESULT, problèmes potentiels de gestion de la mémoire, et l'usage d'opérateur invalide. De plus, il identifie d'autres problèmes qui peuvent être de simples erreur de frappe mais apparaissent dans le code comme des erreurs de format, de casting, etc?

Pour plus d'information, voir ici.

Application Verifier

Disponible dans l'outil Windows Embedded CE 6.0 Test Kit (CETK), l'Application Verifier est un outil qui garanti la stabilité d'une application. Il peut non seulement détecter les problèmes de sécurité, mais peut aussi identifier les erreurs communes de programmation.

L'application Verifier a pour principe de surveiller l'utilisation par une application du système d'exploitation (système de fichier, registre, mémoire et les API) pendant que ladite application s'exécute. L'outil fourni ensuite des indications pour la correction et l'ajustement du code source pour les problèmes détectés.

L'outil vous permet :

  • D'identifier les fuites mémoire et les corruptions de tas, dont les débordements de buffer, ou les problèmes avec les blocs mémoire déplaçables.
  • De trouver et gérer les oublis de typage des Handles tels que les Handles de registre, fichier, évènement, ou section critique.
  • De déterminer certains types de problème avec les objets GDI et les objets définis par l'utilisateur.

Pour plus d'information et les instructions de mise en oeuvre, voir ici.

Conclusion

On a pu voir au travers de cet article que Windows Embedded CE 6.0 est un système d'exploitation qui s'avère être plus sécurisé que jamais. L'architecture même de l'OS et les diverses fonctionnalités évoquées permettent de constituer un OS sécurisé.

Il n'en reste pas moins que le rôle du développeur est primordial lorsque la question de la sécurité est posée.

Celui-ci dispose, grâce aux outils Visual Studio 2005 et Platform Builder 6.0 d'une panoplie très complète d'outils, de librairies, de compilateurs, et de technologies complémentaires l'aidant à créer un système, des drivers et des applications qui pourront non seulement être adaptés et optimisés pour un usage particulier, mais qui garantiront aussi un fonctionnement stable, performant, sûr.

Il aura la possibilité de ne plus devoir complètement fermer son système pour se prémunir de tout risque, mais d'ouvrir sa plateforme embarquée tout en garantissant un fonctionnement robuste et stable.