Práticas recomendadas de instalação para jogos online multijogador massivo
Este artigo descreve a criação de um projeto de cadeia de confiança para a instalação de clientes de jogos online para vários jogadores em massa (MMOG) e sistemas de atualização de jogos personalizados que funcionam bem com o Windows e com o modelo de segurança do Windows Vista e do Windows 7. A abordagem foi projetada para permitir a correção de títulos MMOG e, ao mesmo tempo, oferecer suporte a contas de usuário padrão, que têm acesso restrito ao disco rígido e ao registro do sistema.
- Por que os clientes de MMOGs têm requisitos diferentes dos jogos tradicionais comprados no varejo
- Visão geral de uma abordagem de cadeia de confiança
- Tudo é validado no servidor, por que devo me preocupar se meu cliente for hackeado?
- Construção do aplicativo Trust-Worthy Loader
Por que os clientes de MMOGs têm requisitos diferentes dos jogos tradicionais comprados no varejo
A natureza constantemente conectada e em evolução dos MMOGs torna um requisito fundamental fornecer atualizações regulares do código e conteúdo do cliente para corrigir vulnerabilidades de segurança e estender a experiência de jogo. Com a possibilidade de atualizações quase diárias, o cenário de MMOG exige um gerenciamento cuidadoso para garantir uma experiência de usuário agradável. Isso difere do modelo tradicional de compra no varejo, onde um pequeno número de patches pode ser fornecido próximo à data de envio do produto. A tecnologia de aplicação de patch de usuário limitada do Windows Installer fornecida com o sistema operacional, foi projetada para lidar com um pequeno número de patches de aplicativos, e não com a grande quantidade e alta frequência necessária para MMOGs. Portanto, muitas vezes é necessário que sistemas de patch personalizados sejam desenvolvidos para atender às necessidades dos MMOGs, incluindo quaisquer requisitos especiais específicos para o MMOG específico que está sendo desenvolvido.
Como muitos computadores estão conectados à Internet, o Windows Vista e o Windows 7 têm restrições de segurança e proteções mais rígidas para os usuários, o que limita o acesso que os aplicativos têm a várias áreas do disco rígido. Ao contrário do Windows XP, essas restrições são habilitadas para o modo padrão para contas de usuário. Essas restrições devem ser levadas em consideração ao projetar o layout de um jogo, executável e dados, e seu sistema de patch associado. Para obter mais detalhes sobre as medidas de segurança fornecidas pelo sistema operacional, consulte Controle de conta de usuário para desenvolvedores de jogos.
Visão geral de uma abordagem de cadeia de confiança
A abordagem de atualização personalizada apresentada neste white paper baseia-se em ter um aplicativo carregador confiável instalado na pasta Arquivos de Programas protegidos, mantendo os arquivos executáveis e dados do jogo em uma área compartilhada e acessível a todos os usuários. Uma cadeia de confiança começa com o carregador, que executa verificações de validade nos binários e dados do jogo antes do lançamento.
O carregador confiável precisa ter lógica suficiente para poder verificar se o executável do jogo e outros binários não foram adulterados antes de iniciar o jogo. O carregador também pode verificar os dados do jogo quantas vezes forem necessárias, no entanto, o tamanho dos dados do jogo geralmente é muito grande para permitir que sejam verificados todas as vezes em uma única passagem. Uma abordagem alternativa é usar um padrão de amostragem que garanta que a verificação de todo o conjunto de dados ocorra em um período de tempo prolongado. O aplicativo carregador pode conter um mecanismo de patch de jogo, que fornece um método confiável para integrar atualizações ao jogo instalado.
Tudo é validado no servidor, por que devo me preocupar se meu cliente for hackeado?
É impossível confiar que o cliente não foi comprometido, portanto, é comum que os servidores MMOG validem todos os dados recebidos do cliente. Embora esse processamento possa identificar clientes de jogos comprometidos ou trapaceiros desse universo, o servidor não pode identificar facilmente todos os problemas aos quais o cliente do jogo pode estar exposto. É importante fortalecer a proteção contra hackers que desejam usar seu cliente como uma plataforma para ataques ao seu serviço, a outros usuários ou até mesmo como um vetor para atacar as próprias máquinas clientes. A aplicação de técnicas de assinatura de código e verificação de dados pode ajudar a detectar clientes comprometidos antes que eles sejam executados. Como o mecanismo de aplicação de patch requer a exposição de binários executáveis e DLL que não são protegidos pelas permissões somente leitura padrão em Arquivos de Programas, validar esses arquivos antes de iniciá-los é importante para a segurança geral do sistema.
Esse modelo não tenta lidar com o cenário do usuário administrador malicioso em que o próprio carregador pode ficar comprometido, mas se concentra em proteger os usuários padrão contra a execução acidental de código adulterado. As técnicas tradicionais de validação entre servidor e cliente são, na verdade, a única atenuação possível para administradores de sistemas de clientes maliciosos.
Construção do aplicativo Trust-Worthy Loader
Leitura em segundo plano
Os leitores devem se familiarizar com a documentação a seguir, que fornece detalhes da tecnologia básica para garantir as melhores práticas de confiança baseada em software.
-
Assinatura de Código
-
SignTool
-
SignTool no MSDN
A seção a seguir detalha as APIs que devem ser usadas para construir o aplicativo carregador, que dão suporte ao layout do disco para instalação e verificação da verificação de confiança.
Instalação do Trusted Loader e patcher
O carregador confiável e a versão base do utilitário patcher devem ser instalados na pasta Arquivos de Programas protegidos no HD, assim como nas instalações tradicionais. A instalação e a aplicação de patches do aplicativo carregador requerem direitos de administrador, portanto, é importante minimizar a frequência de atualização do carregador para garantir que os usuários finais não precisem se elevar com frequência, embora a aplicação de patches pelo usuário limitado do Windows Installer possa ser usada para evitar a elevação para patches do carregador.
Consulte o artigo Corrigindo software de jogo no Windows XP, Windows Vista e Windows 7.
Instalação dos executáveis, DLLs e dados do jogo
Para facilitar as atualizações do usuário padrão do jogo sem privilégio administrativo, o executável do jogo, as DLLs e os dados devem ser instalados em uma área do disco rígido acessível para gravação e para todos os usuários. O sistema operacional fornece uma área "Dados do aplicativo de todos os usuários" que pode ser usada como o local padrão para instalação. SHGetFolderPath deve ser usado com a chave CSIDL_COMMON_APPDATA para determinar o caminho do arquivo para essa área. É importante que nenhuma suposição seja feita sobre o caminho para o qual essa chave retorna, pois ela pode ser configurável pelo usuário.
A instalação precisa alterar ou gerenciar as permissões da pasta para obter o acesso de gravação compartilhado por todos os usuários necessário para atualizar o título. Com as permissões corretas, a funcionalidade do atualizador de jogos do programa carregador pode facilmente corrigir o jogo sem a necessidade de privilégios especiais de qualquer conta de usuário, inclusive quando iniciado por usuários padrão.
Código de modificação da lista de controle de acesso
Para o Windows XP, você precisará executar o código para alterar a lista de controle de acesso (ACL) manualmente, aqui está um exemplo de função que demonstra como fazer isso:
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;
}
Este exemplo de código também funcionará para o Windows Vista e o Windows 7, no entanto, eles também fornecem o utilitário de linha de comando icacls para editar o arquivo ACLS que você pode optar por usar.
A ferramenta fornece uma ajuda detalhada quando executada, no entanto, um exemplo de uso da ferramenta é:
icacls "C:\Users\All Users\Game" /grant Rex:(D,WDAC)
Esse uso concederá ao usuário as permissões Rex Delete e Write DAC para a pasta do jogo armazenada nas áreas Todos os usuários do disco rígido.
Instalações para usuários Advanced
Para cenários de instalação de usuários Advanced, um usuário pode querer especificar o caminho de instalação dos jogos manualmente. A seleção do diretório deve ser restrita para fora dos arquivos de programa para garantir que a pasta esteja em uma área realmente compartilhável do disco rígido. O caminho selecionado pelo usuário deve ser usado apenas para os exes e dados do jogo, pois o Loader do jogo e o Patcher exes devem sempre ser instalados na pasta segura de Arquivos de Programas para melhor segurança.
A verificação de confiança do Loader
O Windows fornece a função WinVerifyTrust para verificar a validade do código assinado e se baseia nos serviços criptográficos do sistema operacional. A função está totalmente documentada no MSDN: função WinVerifyTrust.
Para obter mais detalhes sobre o uso da função para determinar se um executável de programa está assinado com um certificado válido, consulte Exemplo de programa C: verificando a assinatura de um arquivo PE.
Para verificar se o executável do jogo assinado é confiável para ser executado de dentro do carregador, a ação verificação genérica será suficiente:
-
Valor
-
WINTRUST_ACTION_GENERIC_VERIFY_V2
-
Significado
-
Verifique um arquivo ou objeto usando o provedor de políticas Authenticode.
A função recebe um argumento de estrutura de entrada que contém informações que o provedor de confiança precisa para processar a ação especificada. Normalmente, como no caso de exemplo anterior, a estrutura inclui informações que identificam o objeto que o provedor de confiança deve avaliar.
O formato da estrutura é específico para o identificador de ação. Para obter mais detalhes sobre uma estrutura de exemplo para o provedor WinTrust, consulte a estrutura WINTRUST_DATA.
Se o provedor de confiança verificar que a entidade é confiável para a ação especificada, o valor retornado será zero. Nenhum outro valor além de zero deve ser considerado um retorno bem-sucedido.
Validação de Dados
O mecanismo de codesign só dá suporte à assinatura de alguns tipos específicos de arquivos, incluindo executáveis, DLLs, pacotes do Windows Installer (arquivos .msi) e arquivos de gabinete (.cab). A API WinVerifyTrust não deve ser usada para verificar se arquivos de dados grandes (arquivos .cab, por exemplo) não foram adulterados, pois há alguns problemas de desempenho e estabilidade na validação. Os executáveis do programa tendem a ser pequenos o suficiente para que uma verificação de confiança total ocorra usando o provedor WinTrust, mas os arquivos de dados para jogos geralmente têm muitos gigabytes. A abordagem adotada pelo carregador para verificação dos dados do jogo deve ser aquela em que uma pequena amostra do conjunto de dados é testada durante o tempo de execução do jogo. Essa abordagem distribui o custo dos testes de verificação ao longo da vida útil da experiência de jogo e pode fornecer uma experiência de usuário perfeita sem longos tempos de espera. Para conseguir isso, pode ser necessária uma organização cuidadosa dos dados. Alguns MMOGs empregam uma abordagem de banco de dados para ajudar a gerenciar, manter e verificar a exatidão dos ativos do jogo ao longo do tempo.
Do ponto de vista da segurança, o código do cliente deve ser projetado para não confiar em arquivos de dados, mesmo se estiver usando algum tipo de validação básica de dados com o carregador confiável. Verificações de cabeçalho, hashes e outras verificações de integridade tradicionais devem ser utilizadas. O trabalho para fortalecer o código de E/S do cliente também deve ser feito usando técnicas como teste de fuzz, além de aproveitar as vantagens das ferramentas de análise automática de código estático, como o /analyze no Visual Studio 2005 e no Visual Studio 2008 (disponível no Visual Studio Team System e no compilador gratuito que acompanha o SDK do Windows).
Para obter mais informações sobre segurança de software, consulte Práticas recomendadas de segurança no desenvolvimento de jogos.