Partager via


Bonnes pratiques d’installation pour les jeux massivement multijoueurs en ligne

Cet article décrit la création d’une chaîne de conception de confiance pour l’installation de clients de jeux massivement multijoueurs en ligne (MMOG) et les systèmes de mise à jour personnalisés de jeux qui fonctionnent bien avec Windows et le modèle de sécurité de Windows Vista et Windows 7. L’approche est conçue pour permettre la mise à jour des titres MMOG tout en prenant en charge les comptes d’utilisateurs standard, qui ont un accès restreint au disque dur et au registre système.

Pourquoi les clients MMOG ont-ils des exigences différentes par rapport aux jeux achetés en magasin traditionnel

La nature constamment connectée et évolutive des MMOG rend nécessaire de fournir des mises à jour régulières du code client et du contenu pour corriger les vulnérabilités de sécurité et prolonger l’expérience de jeu. Avec la possibilité de mises à jour presque quotidiennes, le scénario MMOG nécessite une gestion minutieuse pour garantir une expérience conviviale. Cela diffère du modèle d’achat en magasin traditionnel où un petit nombre de correctifs peut être fourni près de la date de sortie au détail du produit. La technologie de patching pour utilisateurs limités de l’installateur Windows fournie avec le système d’exploitation est conçue pour gérer un petit nombre de correctifs d’application, et non la grande quantité et la haute fréquence nécessaires pour les MMOG. Il est donc souvent nécessaire de développer des systèmes de patching personnalisés pour répondre aux besoins des MMOG, y compris toute exigence spéciale spécifique au MMOG particulier en cours de développement.

Étant donné que de nombreux ordinateurs sont connectés à Internet, Windows Vista et Windows 7 ont des restrictions de sécurité et des mesures de protection plus strictes pour les utilisateurs, qui limitent l’accès des applications à diverses zones du disque dur. Contrairement à Windows XP, ces restrictions sont activées pour le mode par défaut des comptes d’utilisateurs. Ces restrictions doivent être prises en compte lors de la conception de la mise en page d’un jeu, de son exécutable et de ses données, et de son système de patching associé. Pour plus de détails sur les mesures de sécurité fournies par le système d’exploitation, veuillez consulter la section Contrôle de compte d’utilisateur pour les développeurs de jeux.

Vue d’ensemble d’une approche de chaîne de confiance

L’approche de mise à jour personnalisée présentée dans ce livre blanc repose sur l’installation d’une application de chargeur digne de confiance dans le dossier protégé Program Files tout en gardant les fichiers exécutables et les données des jeux dans une zone partagée accessible à tous les utilisateurs. Une chaîne de confiance commence avec le chargeur qui effectue des vérifications de validité sur les binaires et les données du jeu avant le lancement.

La chaîne de confiance commence avec un chargeur digne de confiance

Le chargeur digne de confiance doit avoir suffisamment de logique pour pouvoir vérifier que l’exécutable du jeu et les autres binaires n’ont pas été altérés avant de lancer le jeu. Le chargeur peut également vérifier les données du jeu aussi souvent que nécessaire, cependant, la taille des données du jeu est généralement trop grande pour permettre une vérification complète à chaque fois en une seule passe. Une approche alternative consiste à utiliser un schéma d’échantillonnage qui garantit que la vérification de l’ensemble des données se fait sur une période prolongée. L’application du chargeur peut contenir un moteur de patching de jeu, qui fournit une méthode digne de confiance pour intégrer les mises à jour avec le jeu installé.

Tout est validé sur le serveur, pourquoi devrais-je m’inquiéter si mon client est piraté ?

Il est impossible de garantir que le client n’a pas été compromis ; il est donc courant que les serveurs MMOG valident toutes les données reçues du client. Bien que ce traitement puisse identifier les clients de jeu compromis ou tricheurs au sein de l’univers du jeu, le serveur ne peut pas facilement identifier tous les problèmes auxquels le client de jeu peut être exposé. Il est important de renforcer la protection contre les hackers qui souhaitent utiliser votre client comme plateforme pour des attaques sur votre service, d’autres utilisateurs, ou même simplement comme vecteur d’attaque des machines clientes elles-mêmes. L’application des techniques de signature de code et de vérification des données peut aider à détecter les clients compromis avant leur exécution. Étant donné que le mécanisme de patching nécessite l’exposition de binaires exécutables et DLL qui ne sont pas protégés par les permissions standard en lecture seule de Program Files, il est important de valider ces fichiers avant de les lancer pour la sécurité globale du système.

Ce modèle ne tente pas de traiter le scénario de l’utilisateur administrateur malveillant où le chargeur lui-même pourrait être compromis, mais se concentre sur la protection des utilisateurs standard contre l’exécution accidentelle de code altéré. Les techniques traditionnelles de validation serveur-client sont vraiment la seule mitigation possible pour les administrateurs système clients malveillants.

Construction de l’application de chargement digne de confiance

Lecture en arrière-plan

Les lecteurs doivent se familiariser avec la documentation suivante, qui fournit des détails sur la technologie de base pour assurer les bonnes pratiques de confiance logicielle.

Signature de code

Signature Authenticode pour les développeurs de jeux

SignTool (SignTool)

SignTool sur MSDN

La section suivante détaille les API qui doivent être utilisées pour construire l’application de chargement, qui supportent la mise en page du disque pour l’installation et la vérification de la confiance.

Installation du chargeur et du patcher de confiance

Le chargeur de confiance et la version de base de l’utilitaire de patch doivent être installés dans le dossier protégé Program Files sur le disque dur comme dans les installations traditionnelles. L’installation et le patching de l’application de chargement nécessitent des droits d’administrateur, il est donc important de minimiser la fréquence des mises à jour du chargeur pour s’assurer que les utilisateurs finaux n’ont pas besoin de s’élever souvent, bien que le patching pour utilisateurs limités de l’installateur Windows puisse être utilisé pour éviter l’élévation pour les patchs du chargeur.

Veuillez consulter l’article Correctif logiciel de jeu dans Windows XP, Windows Vista et Windows 7.

Installation des exécutables de jeu, des DLL et des données

Afin de faciliter les mises à jour du jeu par les utilisateurs standard sans privilège administratif, les exécutables du jeu, les DLL et les données doivent être installés dans une zone du disque dur accessible en écriture pour tous les utilisateurs. Le système d’exploitation fournit une zone « All Users Application Data » qui peut être utilisée comme emplacement par défaut pour l’installation. SHGetFolderPath doit être utilisé avec la clé CSIDL_COMMON_APPDATA pour déterminer le chemin d’accès à cette zone. Il est important de ne faire aucune hypothèse sur le chemin retourné par cette clé car il peut être configurable par l’utilisateur.

L’installation doit modifier ou gérer les permissions du dossier pour obtenir l’accès en écriture partagé par tous les utilisateurs nécessaire pour la mise à jour du titre. Avec les permissions correctes, la fonctionnalité de mise à jour du jeu du programme de chargement peut facilement patcher le jeu sans besoin de privilège spécial de la part de tout compte utilisateur, y compris lorsqu’il est lancé par des utilisateurs standard.

Code de modification de la liste de contrôle d’accès

Pour Windows XP, vous devrez exécuter du code pour modifier manuellement la liste de contrôle d’accès (ACL), voici un exemple de fonction qui démontre comment le faire :

HRESULT ChangeACLtoAllowUserRW( WCHAR* strDir )
{
    EXPLICIT_ACCESS explicitaccess;
    PACL NewAcl = NULL;
    DWORD dwError;

    BuildExplicitAccessWithName( &explicitaccess, L"BUILTIN\\Users",
                                 GENERIC_ALL, GRANT_ACCESS,
                                 SUB_CONTAINERS_AND_OBJECTS_INHERIT );
                                 
    dwError = SetEntriesInAcl( 1, &explicitaccess, NULL, &NewAcl );
    if( dwError == ERROR_SUCCESS) 
    {
        dwError = SetNamedSecurityInfo( strDir, SE_FILE_OBJECT,
                                        DACL_SECURITY_INFORMATION,
                                        NULL, NULL, NewAcl, NULL );
        if( dwError == ERROR_SUCCESS)
        {
            if( NewAcl != NULL ) AccFree( NewAcl );
            return S_OK;
        }
    }

    if( NewAcl != NULL ) AccFree( NewAcl );
    return E_FAIL;
}

Cet exemple de code fonctionnera également pour Windows Vista et Windows 7 ; cependant, ils fournissent également l’utilitaire en ligne de commande icacls pour modifier les ACL des fichiers que vous pouvez choisir d’utiliser à la place.

L’outil fournit une aide détaillée lorsqu’il est exécuté, cependant, voici un exemple d’utilisation pour l’outil :

icacls "C:\Users\All Users\Game" /grant Rex:(D,WDAC)

Cette utilisation accordera à l’utilisateur Rex les permissions de suppression et d’écriture DAC au dossier de jeu stocké dans les zones All Users du disque dur.

Installations pour utilisateurs avancés

Pour les scénarios d’installation pour utilisateurs avancés, un utilisateur peut vouloir spécifier manuellement le chemin d’installation des jeux. La sélection du répertoire doit être limitée à une zone en dehors des Program Files pour s’assurer que le dossier est dans une zone réellement partageable du disque dur. Le chemin sélectionné par l’utilisateur ne doit être utilisé que pour les exécutables et les données des jeux car les exécutables du chargeur et du patcher doivent toujours être installés dans le dossier sécurisé Program Files pour une meilleure sécurité.

Vérification de la confiance par le chargeur

Windows fournit la fonction WinVerifyTrust pour vérifier la validité du code signé et est basée sur les services cryptographiques du système d’exploitation. La fonction est entièrement documentée sur MSDN : Fonction WinVerifyTrust.

Pour plus de détails concernant l’utilisation de la fonction pour déterminer si un exécutable de programme est signé avec un certificat valide, veuillez consulter Example C Program: Verifying the Signature of a PE File.

Aux fins de vérifier que l’exécutable du jeu signé est digne de confiance pour être exécuté depuis le chargeur, l’action de vérification générique suffira :

Valeur

WINTRUST_ACTION_GENERIC_VERIFY_V2

Signification

Vérifier un fichier ou un objet en utilisant le fournisseur de politique Authenticode.

La fonction prend un argument de structure d’entrée qui contient les informations dont le fournisseur de confiance a besoin pour traiter l’action spécifiée. En règle générale, comme dans l’exemple précédent, la structure inclut des informations qui identifient l’objet que le fournisseur de confiance doit évaluer.

Le format de la structure est spécifique à l’identifiant de l’action. Pour plus de détails sur une structure d’exemple pour le fournisseur WinTrust, veuillez consulter la Structure WINTRUST_DATA.

Si le fournisseur de confiance vérifie que le sujet est digne de confiance pour l’action spécifiée, la valeur de retour est zéro. Aucune autre valeur en dehors de zéro ne doit être considérée comme un retour réussi.

Validation des données

Le mécanisme de signature de code ne supporte que la signature de quelques types spécifiques de fichiers, y compris les exécutables, les DLL, les packages d’installation Windows (.msi files), et les fichiers cabinet (.cab). L’API WinVerifyTrust ne doit pas être utilisée pour vérifier que les grands fichiers de données (par exemple les fichiers .cab) n’ont pas été altérés, car il y a des problèmes de performance et de stabilité lors de la validation de très grands fichiers. Les exécutables de programme tendent à être suffisamment petits pour qu’une vérification complète de la confiance puisse avoir lieu en utilisant le fournisseur WinTrust, mais les fichiers de données pour les jeux sont souvent de l’ordre de plusieurs gigaoctets. L’approche adoptée par le chargeur pour la vérification des données du jeu devrait être celle où un petit échantillon de l’ensemble des données est testé pendant la durée d’exécution du jeu. Cette approche répartit le coût des tests de vérification sur la durée de l’expérience de jeu et peut fournir une expérience utilisateur sans attente prolongée. Pour y parvenir, une organisation soignée des données peut être nécessaire. Certains MMOGs utilisent une approche de base de données pour aider à gérer, maintenir et vérifier la correction des actifs de jeu au fil du temps.

Du point de vue de la sécurité, le code client doit être conçu pour ne pas faire confiance aux fichiers de données même en utilisant une sorte de validation de base des données avec le chargeur de confiance. Des vérifications d’en-tête, des hachages et d’autres vérifications traditionnelles d’intégrité doivent être employés. Un travail pour renforcer le code I/O du client doit également être effectué en utilisant des techniques telles que les tests de fuzz ainsi que profiter des outils d’analyse statique de code automatique tels que le switch /analyze dans Visual Studio 2005 et Visual Studio 2008 (disponible dans Visual Studio Team System et le compilateur gratuit fourni avec le SDK Windows).

Pour plus d’informations sur la sécurité logicielle, Veuillez consulter la section Bonnes pratiques de sécurité dans le développement de jeux.