Udostępnij za pośrednictwem

Najlepsze praktyki dotyczące instalacji gier MMO (Massively Multiplayer Online)

W tym artykule opisano tworzenie projektu łańcucha zaufania dla instalacji klienta gier sieciowych typu Massively Multiplayer Online Games (MMOG) i niestandardowych systemów aktualizacji gier, które dobrze współpracują z systemami Windows oraz modelem zabezpieczeń Windows Vista i Windows 7. Podejście to ma na celu włączenie poprawek tytułów MMOG przy jednoczesnym obsłudze kont użytkowników standardowych, które mają ograniczony dostęp do dysku twardego i rejestru systemowego.

Dlaczego klienci MMOG mają różne wymagania dotyczące tradycyjnych gier zakupionych w sprzedaży detalicznej

Stale połączony i ewoluujący charakter MMOG sprawia, że podstawowym wymaganiem jest zapewnienie regularnych aktualizacji kodu klienta i zawartości w celu naprawienia luk w zabezpieczeniach i rozszerzenia środowiska rozgrywki. Dzięki możliwości niemal codziennych aktualizacji scenariusz MMOG wymaga starannego zarządzania w celu zapewnienia przyjaznego dla użytkownika środowiska. Różni się to od tradycyjnego modelu zakupu detalicznego, w którym niewielka liczba poprawek może być dostarczona blisko daty wysyłki detalicznej produktu. Technologia ograniczonego stosowania poprawek przez Instalatora Windows dostarczana z systemem operacyjnym jest przeznaczona do obsługi niewielkiej liczby poprawek aplikacji, a nie dużej ilości i wysokiej częstotliwości wymaganej przez MMOG. W związku z tym często konieczne jest opracowanie niestandardowych systemów poprawek w celu zaspokojenia potrzeb MMOG, w tym wszelkich specjalnych wymagań specyficznych dla opracowywanego programu MMOG.

Ponieważ tak wiele komputerów jest połączonych z Internetem, systemy Windows Vista i Windows 7 mają ostrzejsze ograniczenia zabezpieczeń i zabezpieczenia dla użytkowników, co ogranicza dostęp aplikacji do różnych obszarów dysku twardego. W przeciwieństwie do systemu Windows XP te ograniczenia są włączone dla trybu domyślnego dla kont użytkowników. Te ograniczenia należy wziąć pod uwagę podczas projektowania układu gry, pliku wykonywalnego i danych oraz skojarzonego z nim systemu stosowania poprawek. Aby uzyskać więcej informacji na temat środków zabezpieczeń udostępnianych przez system operacyjny, zobacz Kontrola konta użytkownika dla deweloperów gier.

Omówienie podejścia opartego na łańcuchu zaufania

Niestandardowe podejście aktualizacji przedstawione w tym oficjalnym dokumencie opiera się na zainstalowaniu zaufanej aplikacji ładującego w chronionym folderze Program Files przy zachowaniu plików wykonywalnych gier i danych w udostępnionym obszarze dostępnym dla wszystkich użytkowników. Łańcuch zaufania rozpoczyna się od modułu ładującego, który przeprowadza sprawdzanie poprawności plików binarnych i danych gry przed uruchomieniem.

łańcuch zaufania rozpoczyna się od zaufanego modułu ładującego

Zaufany moduł ładujący musi mieć wystarczającą logikę, aby móc sprawdzić, czy plik wykonywalny gry i inne pliki binarne nie zostały naruszone przed uruchomieniem gry. Moduł ładujący może również zweryfikować dane gry tak często, jak to konieczne, jednak rozmiar danych gry jest zwykle zbyt duży, aby umożliwić ich sprawdzenie za każdym razem w jednym przejściu. Alternatywną metodą jest użycie wzorca próbkowania, który gwarantuje, że weryfikacja całego zestawu danych odbywa się przez dłuższy czas. Aplikacja modułu ładującego może zawierać silnik do łatania gier, który zapewnia wiarygodną metodę integrowania aktualizacji z zainstalowaną grą.

Wszystko jest weryfikowane na serwerze, dlaczego należy się martwić, jeśli mój klient zostanie zhakowany?

Nie można ufać, że klient nie został naruszony; dlatego często serwery MMOG weryfikują wszystkie dane odebrane od klienta. Chociaż przetwarzanie to może identyfikować naruszonych lub oszukiwanych klientów gry we wszechświecie gry, serwer nie może łatwo zidentyfikować wszystkich problemów, z których klient gry może być narażony. Ważne jest wzmocnienie ochrony przed hakerami, którzy chcą używać klienta jako platformy do ataków na usługę, innych użytkowników, a nawet po prostu jako wektor do ataku na same maszyny klienckie. Zastosowanie technik podpisywania kodu i weryfikacji danych może pomóc wykryć naruszonych klientów przed ich wykonaniem. Ponieważ mechanizm stosowania poprawek wymaga uwidaczniania plików wykonywalnych i plików binarnych DLL, które nie są chronione przez standardowe uprawnienia tylko do odczytu w programach, sprawdzanie poprawności tych plików przed ich uruchomieniem jest ważne w przypadku ogólnych zabezpieczeń systemu.

Ten model nie próbuje radzić sobie ze scenariuszem złośliwego użytkownika administratora, w którym sam moduł ładujący może zostać naruszony, ale koncentruje się na ochronie użytkowników standardowych przed przypadkowym uruchomieniem naruszonego kodu. Tradycyjne techniki weryfikacji klienta serwera są naprawdę jedynym możliwym ograniczeniem ryzyka dla złośliwych administratorów systemu klienta.

Konstrukcja aplikacji modułu ładującego Trust-Worthy

Czytanie w tle

Czytelnicy powinni zapoznać się z następującą dokumentacją, która zawiera szczegółowe informacje na temat technologii podstawowych w celu zapewnienia najlepszych rozwiązań w zakresie zaufania opartego na oprogramowaniu.

podpisywanie kodu

Podpisywanie Authenticode dla Twórców Gier

SignTool

SignTool na MSDN

W poniższej sekcji szczegółowo opisuje się interfejsy API, które powinny być używane do konstruowania aplikacji ładującej, która obsługuje układ dysków do instalacji i weryfikacji zaufania.

Instalacja zaufanego programu ładującego i narzędzia do łatania

Zaufany moduł ładujący i podstawowa wersja narzędzia patchera powinny być instalowane w folderze chronionych plików programu na dysku TWARDYM tak samo jak w tradycyjnych instalacjach. Instalacja i stosowanie poprawek aplikacji modułu ładującego wymaga uprawnień administratora, dlatego ważne jest zminimalizowanie częstotliwości aktualizacji modułu ładującego w celu zapewnienia, że użytkownicy końcowi nie muszą często podnosić poziomu, chociaż instalator Windows może użyć ograniczonych poprawek użytkownika, aby uniknąć podniesienia uprawnień w przypadku poprawek modułu ładującego.

Zobacz artykuł "Stosowanie poprawek do oprogramowania gier w systemach Windows XP, Windows Vista i Windows 7".

Instalacja plików wykonywalnych, bibliotek DLL i danych gry

Aby ułatwić użytkownikom standardowym aktualizacje gry bez uprawnień administracyjnych, pliki wykonywalne gry, biblioteki DLL i dane muszą być zainstalowane w obszarze dysku twardego, który jest dostępny dla wszystkich użytkowników. System operacyjny udostępnia obszar "Wszystkie dane aplikacji użytkowników", który może być używany jako domyślna lokalizacja instalacji. shGetFolderPath należy użyć z kluczem CSIDL_COMMON_APPDATA, aby określić ścieżkę pliku dla tego obszaru. Ważne jest, aby nie stosować żadnych założeń dotyczących ścieżki, do której ten klucz jest zwracany, ponieważ może być konfigurowalny przez użytkownika.

Instalacja musi zmienić uprawnienia do folderu lub nimi zarządzać, aby uzyskać współdzielony dostęp do zapisu dla wszystkich użytkowników, niezbędny do zaktualizowania tytułu. Dzięki poprawnym uprawnieniom funkcja aktualizatora gier programu ładującego może łatwo zastosować poprawki do gry bez konieczności posiadania specjalnych uprawnień z żadnego konta użytkownika, nawet gdy jest uruchamiany przez użytkowników standardowych.

Kod modyfikacji listy kontroli dostępu

W przypadku systemu Windows XP należy wykonać kod, aby ręcznie zmienić listę kontroli dostępu (ACL), oto przykładowa funkcja, która pokazuje, jak to zrobić:

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;
}

Ten przykład kodu będzie również działać w systemach Windows Vista i Windows 7; jednak udostępniają również narzędzia wiersza polecenia icacls do edycji plików ACLS, których można użyć zamiast tego.

Narzędzie udostępnia szczegółową pomoc w przypadku wykonania, jednak jednym z przykładów użycia tego narzędzia jest:

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

To użycie przyzna użytkownikowi uprawnienia Rex Delete i Write DAC do folderu gry przechowywanego w obszarach Wszyscy użytkownicy dysku twardego.

Instalacje dla użytkowników zaawansowanych

W przypadku zaawansowanych scenariuszy instalacji użytkowników użytkownik może chcieć ręcznie określić ścieżkę instalacji gier. Wybór katalogu powinien być ograniczony do katalogów poza folderami programów, aby upewnić się, że folder znajduje się w naprawdę współdzielonym obszarze dysku twardego. Wybrana przez użytkownika ścieżka powinna być używana tylko do plików .exe gier i danych, ponieważ programy wykonawcze Loader i Patcher zawsze powinny być instalowane w bezpiecznym folderze Program Files, aby zwiększyć bezpieczeństwo.

Weryfikacja zaufania modułu ładującego

System Windows udostępnia funkcję WinVerifyTrust do sprawdzania poprawności podpisanego kodu i jest oparta na usługach kryptograficznych w systemie operacyjnym. Funkcja jest w pełni udokumentowana w witrynie MSDN: WinVerifyTrust Function.

Aby uzyskać więcej informacji na temat używania funkcji w celu określenia, czy plik wykonywalny programu jest podpisany przy użyciu prawidłowego certyfikatu, zobacz Przykładowy program C: Weryfikowanie podpisu pliku PE.

Aby sprawdzić, czy podpisany plik wykonywalny gry jest godny zaufania do wykonania wewnątrz modułu ładującego, wystarczy akcja Weryfikacja ogólna:

wartość

WINTRUST_ACTION_GENERIC_VERIFY_V2

znaczenie

Sprawdź plik lub obiekt przy użyciu dostawcy polityki Authenticode.

Funkcja przyjmuje argument struktury wejściowej zawierający informacje potrzebne dostawcy zaufania do przetworzenia określonej akcji. Zwykle, podobnie jak w poprzednim przykładzie, struktura zawiera informacje identyfikujące obiekt, który musi ocenić dostawca zaufania.

Format struktury jest specyficzny dla identyfikatora akcji. Aby uzyskać więcej informacji na temat przykładowej struktury dostawcy WinTrust, zobacz sekcję WINTRUST_DATA Struktura.

Jeśli dostawca zaufania zweryfikuje, że podmiot jest zaufany dla określonego działania, zwracana wartość to zero. Żadna inna wartość niż zero nie powinna być uznawana za pomyślną wartość zwrotną.

Walidacja danych

Mechanizm współprojektowania obsługuje podpisywanie tylko kilku określonych typów plików, w tym plików wykonywalnych, bibliotek DLL, pakietów Instalatora Windows (.msi plików) i plików cabinet (.cab). Interfejs API WinVerifyTrust nie powinien być używany do sprawdzania, czy duże pliki danych (na przykład pliki.cab) nie zostały naruszone, ponieważ występują pewne problemy z wydajnością i stabilnością podczas walidacji bardzo dużych plików. Pliki wykonywalne programów zwykle są wystarczająco małe, aby możliwe było pełne sprawdzenie zaufania przy użyciu dostawcy WinTrust, ale pliki danych gier często mają rozmiar sięgający wielu gigabajtów. Podejście podjęte przez moduł ładujący do weryfikacji danych gry powinno być takie, w którym niewielka próbka zestawu danych jest testowana w czasie wykonywania gry. Takie podejście rozkłada koszt testów weryfikacyjnych na całe życie środowiska gry i może zapewnić bezproblemowe środowisko użytkownika bez długich czasów oczekiwania. Aby to osiągnąć, może być wymagana staranne organizacja danych. Niektóre MMOG wykorzystują podejście bazy danych, aby pomóc w zarządzaniu, utrzymywaniu i weryfikowaniu poprawności zasobów gier w czasie.

Z punktu widzenia zabezpieczeń kod klienta powinien być zaprojektowany tak, aby nie ufał plikom danych, nawet jeśli używany jest jakiś rodzaj podstawowej walidacji danych z zaufanym ładowaczem. Należy stosować kontrole nagłówków, skróty i inne tradycyjne sprawdzanie integralności. Dokładniejsze zabezpieczenie kodu I/O klienta powinno również obejmować techniki takie jak testowanie rozmyte oraz wykorzystanie automatycznych narzędzi do analizy kodu statycznego, takich jak przełącznik /analyze w programach Visual Studio 2005 i Visual Studio 2008 (dostępny w Visual Studio Team System oraz w bezpłatnym kompilatorze dostarczanym z Windows SDK).

Aby uzyskać więcej informacji na temat zabezpieczeń oprogramowania, zobacz Best Security Practices in Game Development.