Windows (et plus généralement l'ensemble des systèmes graphiques) repose sur un ensemble de messages que le système envoie en permanence aux différents contrôles ou widgets (bouton, fenêtres, zone d'édition...). Par exemple, lorsque vous cliquez dans la zone d'édition suivante : 

windows lui envoie un message : "l'utilisateur à cliqué avec le bouton gauche de la souris", soit plus exactement le message WM_LBUTTONDOWN. A charge du programme gérant le contrôle edit précédent d'effectuer les actions à entreprendre face à ce message (on parle d'évènement).
Le propos de cet article n'étant pas l'étude de ce mécanisme interne clef de Windows, pour appréhender ce sujet, se reporter à myCatch dont la fonction première est une réalisation didactique visant à creuser le domaine...

De la même manière, chaque fois que dans un programme Delphi vous écrivez une ligne de code du genre :

                        button1.enabled := false

 pour désactiver un contrôle, à l'exécution du programme, en pratique, Windows envoie un message particulier à button1 qui en réponse se désactive. Le principe n'est pas propre à Delphi, mais à l'ensemble des langages de programmation sous Windows.
L'erreur la plus fréquente consiste à penser que cela suffit pour désactiver une fonction d'un programme. En pratique, seule l'interface visuelle a été désactivée et un programme comme myCatch peut la réactivre par un simple "glisser-déplacer"...

Pour exemple, prenons le cas des policies Windows qui permettent de restreindre certaines fonctions aux utilisateurs. Das le cas ou la restriction fait complètement disparaître le contrôle, on ne peut rien faire par cette méthode. Si par contre la restriction se contente de désactiver l'accès graphique à une fonction, alors elle est totalement inutile. C'est le cas de la restriction qui "bloque" la modification du proxy dans les connections internet. Lorsque cette règle de blocage est activée, l'onglet connexions des propriétés d'internet explorer est accessible, mais dans les paramètres réseau :

la zone serveur proxy est désactivée :

La première étape consiste à sélectionner cette zone avec la cible de myCatch, et à la déplacer (les groupBox désactivées masquent les contrôles qu'elles contiennent, mais c'est un autre sujet)

Ensuite, il suffit de sélectionner les éléments que l'on veut activer avec la cible de myCatch, et de choisir "actif" dans la zone action de myCatch :

Dans ce cas par exemple, la modification devenue possible des paramètres du serveur proxy est complètement fonctionnelle.

Tout cela ne représente pas réellement une faille de sécurité dans la conception de Windows (et des autres GUI), mais nécessite tout de même que les programmeurs le prenne en compte dans la conception de leur programme.

L'état actif ou désactivé des contrôles graphiques doit être une représentation visuelle d'un état interne du programme. Chaque fois que c'est le contraire qui a été retenu, c'est à dire que l'état interne du programme est le résultat de son aspect visuel, un programme tel que myCatch permettra de passer outre les blocages.
Nombre de programmes (même les meilleurs) comportent des erreurs de conception de ce genre. Imaginons (! dans ce cas, de la fiction à la réalité il n'y a qu'un pas) un programme distribué sous forme "bridée" pour que les utilisateurs puissent le tester. Au démarrage de ce programme, une première fenêtre propose à l'utilisateur un bouton test (exécutant le programme en mode restreint), et une zone d'édition ou l'utilisateur peut saisir un numéro de licence qu'il a par exemple obtenu après achat du logiciel suite à sa période de test. La zone d'édition est "intelligente" et vérifie "à la volée" chaque caractère saisi dans la zone d'édition. Lorsque le numéro de licence saisi est correct, un bouton démarrer s'active automatiquement. Bien sûr, il y a le risque que quelqu'un essaie toute sorte de combinaisons, mais le numéro est si long qu'il vaudrait mieux jouer au loto. Pourtant, si le bouton démarrer ne revérifie pas le numéro saisi, alors myCatch le réactivera et tout fonctionnera comme si le numéro de licence avait été saisi de manière valide. A nouveau, pas vraiment de faille de sécurité...

Les exemples sont innombrables... Un logiciel d'antivirus par exemple bloque certaines modifications de ces paramètres au moyen d'un mot de passe afin que seul une personne habilitée puisse y accéder. Pourtant, une simple "case à cocher" (cf ci-dessous)

permet de définir s'il y a utilisation ou non d'un mot de passe. La case à cocher se désactive une fois le mot de passe saisi, et il faut normalement saisir le mot de passe pour pouvoir y accéder et la "décocher" (ce qui a pour effet de redonner accès aux paramètres). Un simple gliser-déplacer de myCatch permet de réactiver la case à cocher et par la même d'enlever le mot de passe (ou pire d'en saisir un nouveau).

Sous windows 2000, imaginons un poste avec un accès utilisateur et un mot de passe défini. Les policies permettent de bloquer la modification du mot de passe pour éviter qu' un utilisateur le modifie et que le prochain ne puisse plus y accéder. Sur ce poste, l'appui sur les touches CTRL+ALT+DELETE ouvrira la fenêtre habituelle dans un nouveau bureau vide, mais le bouton changer de mot de passe sera désactivé. myCatch à nouveau permettrait de le réactiver et par la même de modifier le mot de passe.  Un blocage important néanmoins freine myCatch, cette fenêtre s'ouvre dans un nouveau bureau (windows NT family gère en réalité plusieurs desktops dont le bureau system utilisé par exemple pour l'économiseur d'écran) dans lequel myCatch n'est pas présent...

Pourtant le puzzle de la connaissance sur les mécanismes de Windows NT s'assemble toujours un peu plus, et on trouve aujourd'hui  sur internet des morceaux de codes permettant de lancer des programmes dans le bureau system... La forteresse NT se fissure très très légèrement...

A suivre...