Discussion :

[petitcoucou31]

Bonjour à tous.

je suis actuellement sur une application embarquée dans un appareil de mesure portable. ET l'utilisateur final ne doit : ni pouvoir accéder, ni même voir l'OS (Windows 7 et 10).
J'ai réussi à cacher le bureau, la barre des taches, le bouton Windows .. donc à la fin du chargement de l'explorateur windows j'ai un écran noir, le temps que mon appli se charge et soit en plein écran.

Jusqu'à la tout va bien, sauf qu'il me reste les touches (Windows, Ctrl+Alt+Sup ...) toutes les touches raccourcis... . J'ai réussi à désactiver certaines touches en agissant sur la base des registres prés un redémarrage du système. Mais bien sur l'administrateur du système lui veut avoir accéder à l'os ... sans booter le système.

Donc je sais cacher/afficher le bureau... à la volé et je voudrai aussi activer/désactiver les raccourcis aussi à la volée.
Mes recherches qui m'ont données quelques pistes dans les fils, je n'ai rien de vraiment fructueux pour faire cela à la volé depuis une application Delphi.

Je viens donc vous solliciter pour voir si vous avez des idées, désactivation des touches, initialisation de base des registres, hook des touche bas niveau + changement de la touche en live...

[Andnotor]

Pour rendre Windows invisible, le mieux est de ne pas démarrer le shell du tout

Tu peux le remplacer par la base des registres (c'est par utilisateur) :
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon -> Shell=MonChemin/MonApp.exe.

Mais si explorer.exe ne démarre pas, les clés Run, RunOnce etc. ne sont pas exécutées. Le mieux est de mettre directement un batch en place qui permettra le cas échéant de démarrer d'autres apps.

Pour l'admin, tu peux simplement ajouter un bouton avec un ShellExecute en runas (donc protégé par mot de passe) qui démarre explorer.exe.
Le plus propre lorsqu'il a terminé serait quant même qu'il quitte la session et la redémarre pour se retrouver à nouveau en mode utilisateur (mais le reboot n'est pas nécessaire).

Ctrl+Alt+Del ne pourra être désactivé que par la politique de groupe.

[petitcoucou31]

bonjour, et merci AndNotor

c'est comme cela que je fait actuellement dans l'appli. Au démarrage et dans la BDR :
1° Mon appli remplace le shell (Explorateur)
2° Les touches spécifiques (Windows, Ctrl+Alt+Del...) sont inhibées
et cela allez pour moi bien pour moi.

Ce que je cherche à faire est une évolution, car le problème (qui en est un que pour le client), c'est par exemple faire une mise à jour logicielle cela lui demande..

1° Lancer le gestionnaire de tache depuis mon appli , (qui a une fonction qui le lance)
2° Lancer l'explorateur de Windows depuis le gestionnaire de taches
3° Tuer mon appli
4° Faire le nécessaire sur mon appli...
5° Relancer mon appli
6° Tuer l'explorateur.
7° Et il n'a pas les touches... CTRL+Alt+Del

Qui d'après lui est fastidieux, d’où ma recherche d'une nouvelle solution en rendant plutôt "non visible" que "non chargé".

Pour les raccourci j'avais vus qu'ont pouvaient les désactiver par la politique de groupe, je vais chercher comment le faire, peut être en lançant un script ou autre chose

L'idéal pour ce client, semble être ==> avoir un bouton "magique" qui a comme effet... Windows est là et hop il est plus là, et hop il de nouveau là ...

[fbalien]

Bonjour

si il n'y a que la mise à jour du programme vous pouvez la gérer depuis lui même
via un bouton maj par exemple qui va
1- renommer le programme d'origine
2- copier le nouveau programme
3- exécuter le nouveau programme
4- quitter l’ancien

perso pour le blocage de windows
je ne vais pas jusqu’à la clé de registre run
je créé une appli avec une forme sans bordure en plein ecran et un FormStyle = fsStayOnTop
sur le FormCloseQuery je check une variable qui autorise ou non la fermeture
au démarrage je masque la barre de tâche

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
procedure VerrouillerBarreDesTaches(booVerrouiller : boolean);
const
  BARRE_DES_TACHES_NOM = 'Shell_traywnd' ;
  FLAGS : array[boolean] of Cardinal =
    ( SWP_SHOWWINDOW
    , SWP_HIDEWINDOW
    ) ;
begin
  SetWindowPos ( FindWindow( BARRE_DES_TACHES_NOM, '') , 0 , 0 , 0 , 0 , 0 , FLAGS[ booVerrouiller ]);
end ;

et j'intercepte le clavier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
function MonGestionnaireClavier( Code : Integer; WPar : WPARAM; LPar : LPARAM):LRESULT; stdcall ;
const
  LLKHF_ALTDOWN = 32 ;
var
  Infos        : PKBDLLHOOKSTRUCT ;
  AppuiSurCTRL : Boolean ;
  AppuiSurALT  : Boolean ;
begin
  Result := 1 ;
  Infos := PKBDLLHOOKSTRUCT(LPar) ;
  case Code of
    HC_ACTION :
    begin
      AppuiSurCTRL := GetAsyncKeyState( VK_CONTROL ) <> 0 ;
      AppuiSurALT  := ( Infos.flags and LLKHF_ALTDOWN = LLKHF_ALTDOWN ) ;
      case Infos.vkCode of
 
        VK_ESCAPE :  // Touche "Echap"
          if AppuiSurCTRL or AppuiSurALT then Exit ;
 
        VK_TAB : // Touche "Tabulation"
          if  AppuiSurALT then Exit ;
 
        // ----- Clavier Microsoft ----- //
        VK_LWIN , // Touche gauche "Windows"
        VK_RWIN , // Touche droite "Windows"
        VK_APPS : // Touche "Applications"
            Exit ;
      end ;
    end ;
  end ;
  Result:= CallNextHookEx(frmMaitre.fGHookClavier, Code, WPar, LPar);
end ;
 
procedure BloquerClavier(booBloque : boolean) ;
const
  WH_KEYBOARD_LL = 13 ;
begin
  if booBloque and (frmMaitre.fGHookClavier =0) then
    frmMaitre.fGHookClavier := SetWindowsHookEx( WH_KEYBOARD_LL, @MonGestionnaireClavier, GetModuleHandle(NIL), 0) ;
  if not booBloque and (frmMaitre.fGHookClavier <> 0) then
  begin
    UnhookWindowsHookEx( frmMaitre.fGHookClavier ) ;
    frmMaitre.fGHookClavier := 0 ;
  end;
end ;

bien évidement on ré-autorise tout à la fermeture

là déjà si il n'y a pas de multi écran çà le fait

si le user qui exécute le programme n'est pas administrateur il est possible d'interdire le kill du processus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
bloquerKill ( GetCurrentProcessId );
 
function bloquerKill (pid : integer) : cardinal;
var
  hpWriteDAC : THandle;
  pdacl : PACL;
  ea : EXPLICIT_ACCESS;
  dwErr : DWORD;
  users : string;
begin
  hpWriteDAC := OpenProcess(WRITE_DAC, false, pid);
 
  users := getstrUserName;
  ea.grfAccessPermissions := STANDARD_RIGHTS_REQUIRED or SYNCHRONIZE or $0FFF;
  ea.grfAccessMode := DENY_ACCESS;
  ea.grfInheritance := NO_INHERITANCE;
  ea.Trustee.pMultipleTrustee := nil;
  ea.Trustee.MultipleTrusteeOperation := NO_MULTIPLE_TRUSTEE;
  ea.Trustee.TrusteeForm := TRUSTEE_IS_NAME;
  ea.Trustee.TrusteeType := TRUSTEE_IS_WELL_KNOWN_GROUP;
  ea.Trustee.ptstrName := PChar(@users[1]);
  pdacl := nil;
  dwErr := SetEntriesInAcl(1, @ea, nil, pdacl);
  if dwErr<>0 then RaiseLastOSError;
 
  dwErr := SetSecurityInfo(hpWriteDAC, winapi.AccCtrl.SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, nil, nil,pdacl, nil);
  if dwErr<>0 then RaiseLastOSError;
 
  LocalFree(THAndle(pdacl));
  CloseHandle(hpWriteDAC);
end;

[Andnotor]

Oublie les hooks de bas niveau, Windows n'aime plus du tout ça.

[petitcoucou31]

Bonjour ,

Déjà merci a toi ...

pour ce qui est de désactiver la barre des taches, être en plein écran sans bordures... tous cela etait OK. Je suis encore sur l'interception et "blocage des touches".

J'ai gratté une peu sur les Hooks bas niveau. J'ai vus des choses bizarres.. comme :

- Pas d'effet immédiat de l'activation du Hook. Par exemple pour une inhibition de la lettre "L". Après l'activation du hook, l'inhibition de la touche "L" devenait active après deux ou trois appuie sur la touche "L", par contre la désactivation du Hook est immédiate.

- Le hook est actif seulement pour l'appli qui le lance... . Étant un Hook de bas niveau, je pensais que l'inhibition des touches se passait au niveau de Windows donc pour toutes les applications actives a ce moment là.

- Après la détection et l'inhibition de la touche ALT, la séquence CTR-ALT-SUP semble toujours active (en relation avec la remarque précédante)

je suis ton conseil sur le Hook de bas niveau, Je vais jeter un coup d’œil plus profond sur ta fonction gestionnaire de clavier qui je pense fera la faire.

Merci a toi AndNotOr

[Andnotor]

- Pas d'effet immédiat de l'activation du Hook. Par exemple pour une inhibition de la lettre "L". Après l'activation du hook, l'inhibition de la touche "L" devenait active après deux ou trois appuie sur la touche "L", par contre la désactivation du Hook est immédiate.

Surprenant !

- Le hook est actif seulement pour l'appli qui le lance... . Étant un Hook de bas niveau, je pensais que l'inhibition des touches se passait au niveau de Windows donc pour toutes les applications actives a ce moment là.

On peut le limiter à un seul thread, ça dépend du 4ème paramètre de SetWindowHookEx. Mais dans l'exemple ci-dessus, il est global.
Après il y a aussi les contraintes liées à une app 32 bits sur un système 64. Si l'app est en UIAccess, le système se débrouille pour rooter les messages (à travers un stub 64 vers 32) mais sinon c'est cuit. Le même problème survient avec les apps du Windows Store.

Mais le problème principal avec les hooks de bas niveau est que toutes les applications du système doivent appeler un callback dans ton processus. Si pour une raison quelconque il se plante, c'est tous le système qui se trouve en deadlock puisque ton app ne répond plus. Pour éviter cela (depuis peut-être Vista), l'OS n'y va pas par quatre chemins : il termine purement et simplement le hook s'il prend trop de temps à s'exécuter (tu n'en es peut-être même pas responsable si le système est surchargé). Et bien sûr, tu ne reçois aucune notification, tu peux juste constater que... ça marche plus !

Il en est différemment (si ce n'est les contraintes 32/64) avec un hook "standard" puisqu'il est injecté dans chaque processus. En cas de problème, c'est un processus qui est en deadlock, pas le système complet (à moins bien sûr que le hook soit très mal foutu).

Les hooks de bas niveau sont à bannir définitivement !

- Après la détection et l'inhibition de la touche ALT, la séquence CTR-ALT-SUP semble toujours active (en relation avec la remarque précédante)

Normal ! Ctrl+Alt+Del n'est pas traité au niveau user mais au niveau kernel.


ps: je ne comprends pas trop ton client qui préfère "ouvrir" le système juste pour éviter quelques actions manuelles

[fbalien]

Bonjour

L'idéal pour ce client, semble être ==> avoir un bouton "magique" qui a comme effet... Windows est là et hop il est plus là, et hop il de nouveau là ...

Là pour çà si tu as bien mis ton app dans la cle shell du HKCU et pas du HKLM
pour afficher windows tu exécutes explorer
pour masquer windows tu kill explorer

[petitcoucou31]

Bonjour a vous deux ...

je pense avoir codé une solution..

Mais je viens répondre à vos questions ...

Pour vous éclairer un peu :
- Il s'agit d'un système portable qui embarque l'informatique donc on parle. Ce système peut recevoir un clavier/souris, mais qui est quasi-toujours seulement avec un petit écran tactile (d’où la simplification des manipulations par les utilisateurs).
- Et tous ces blocages (Windows non "invisible", pas de Ctrl-Alt-Sup ... ) sont dû à un client qui laisse très peut d'actions aux utilisateurs de ces systèmes.
- Sauf quand il a besoin d'utiliser des fonction de Windows ..
- Enfin comme on dit, le client est ...roi !

Par exemple : Le fait qu'il n'y a pas de clavier, d'avoir une interface en plein écran sans barre de titre ou des taches ... , me permettrait de laisser tomber le CTRL-Alt-SUP.. mais non je dois traiter aussi le cas ou quelqu'un pourrait en connecteur un ...

Voici ma solution :

j'ai fait une petite appli qui se lance au démarrage et qui :
* Inhibe les touches critiques (les touches menu....)
* Qui laisse se dérouler l'intégralité du démarrage de Windows, mais sans rien afficher ni icônes, ni barre des taches....un écran noir ! (Sauf le logo du départ)

donc à la fin du démarrage j'ai un écran noir qui est remplacé par mon appli en plein écran (form sans bordure)

j'ai aussi désactivé la sequence Ctrl-Alt-Sup dans la BDR

Si la personne autorisé veut accéder à Windows, il y a deux boutons.
* Un qui ouvre le gestionnaire de tache (pour presque remplacer le Ctrl-Alt-Sup)
* Un autre :
- Qui réactive les touches critiques (les touches menu....)
- Qui ré-affiche l'explorateur ( les icônes, la barre des taches ...) et minimise l'application.
- Un clic sur l'application minimiser restaure tout comme démarrage.