Below is the article I wrote for Software Development Journal about protecting games and applications against hackers. Unfortunately it is in polish. If you feel this article could be valuable for you please let me know and I will translate it.

Zabezpieczanie gier i aplikacji w Adobe Flash

Dowiesz się:

- jak zabezpieczać  swoje gry i aplikacje przed hackerami

Powinieneś wiedzieć:

- jak programować w ActionScript 3.0 na poziomie przynajmniej średnio-zaawansowanym

Wstęp

Tylko nieliczne aplikacje i gry w Internecie są należycie zabezpieczone. Programując w technologii Adobe Flash musisz mieć na uwadze kilka „furtek”, z których korzystają hakerzy przy włamywaniu się do aplikacji. W niniejszym artykule postaram się pokazać Ci co zrobić, aby zabezpieczyć owoce swojej pracy. Skupimy się głównie na grach, jako że to one najczęściej są atakowane przez hackerów.

Flash jest technologią typu client-side. W praktyce oznacza to, że jeśli nie przeniesiesz logiki na serwer (tzw. „cienki klient”) nigdy nie możesz mieć stuprocentowej pewności, że  Twoja aplikacja będzie bezpieczna. Możesz jednak utrudnić zadanie potencjalnemu hakerowi  na tyle, by się zniechęcił.

Cienki klient

Cienki klient jest bezapelacyjnie najpewniejszym rozwiązaniem. Polega na przeniesieniu całej logiki gry lub aplikacji na serwer, podczas gdy Flash zajmuje się jedynie wyświetlaniem wyników i przekazywaniem do serwera kolejnych ruchów klienta. Jest jednak poważna wada takiego podejścia: wszystkie obliczenia wykonywane dotychczas na komputerze klienta zostaną przeniesione na serwer, co w praktyce oznacza dużo wyższe koszty hostingu. Jeżeli bezpieczeństwo jest priorytetem, np. w konkursie z cennymi nagrodami, warto przekonać klienta, by przeznaczył dodatkowe fundusze na utrzymanie serwerów w zamian za spokojny przebieg rywalizacji. Dodatkowym atutem takiego rozwiązania jest brak konieczności wprowadzania innego typu zabezpieczeń, co pozwala na skrócenie czasu produkcji.

W zależności od aplikacji cienki klient może być oparty na przykład na Flash Media Server (gry typu Memo, Snake, proste „turówki”) lub sesji w PHP (np. quiz). W przypadku FMS’a jeśli nie posiadasz licencji możesz skorzystać z usług firm hostingowych, np. Influxis (www.influxis.com) wybierając plan z dużą iloscią jednoczesnych połączeń i małym transferem, jako że zazwyczaj przesyłane są nieduże ilości danych. Dużym atutem FMS’a jest możliwość weryfikacji komunikującego się z nim SWF’a oraz szyfrowany kanał komunikacyjny RTMPE.

Jeśli jednak zastosowanie tego rozwiązania jest z jakiejś przyczyny niemożliwe musisz zadbać, by zminimalizować ryzyko włamania się do Twojej aplikacji. Musisz jednak mieć na uwadze, że niezależnie od ilości zabezpieczeń Twoja gra lub aplikacja nigdy nie będą w 100% bezpieczne, jeżeli logika nie jest ukryta po stronie serwera.

Furtki, czyli o czym musisz pamiętać.

Obfuscator

Absolutną podstawą przy zabezpieczaniu swf’ów jest obfuscator. Jest to program, który na celu ma takie zmodyfikowanie pliku wynikowego, by był on zrozumiały dla maszyny wirtualnej, ale niezrozumiały dla dekompilatora. Przykładowe obfuscatory to np. secureSWF firmy Kindisoft lub SWF Encrypt stworzony przez Amayeta. Przez długi czas prezentujący się obiecująco secureSWF był liderem na rynku, niestety istnieje już oprogramowanie (www.swf-reader.com) odwracające proces, któremu secureSWF poddaje pliki. W praktyce oznacza to, że swf potraktowany secureSWF’em może jednym kliknięciem zostać z powrotem odbezpieczony.

Dlaczego jest to takie ważne? Największym niebezpieczeństwem jest podmiana zmodyfikowanego przez hackera swf’a przez proxy lub bezpośrednio w pamięci procesu przeglądarki. Jeżeli kod Twojego swfa jest jasny i czytelny hacker bez większych trudności może go zmodyfikować i podmienić, co jest niemożliwe do wykrycia. Innymi słowy jeżeli nie zabezpieczysz obfuscatorem swojego swf’a  wszystkie inne zabezpieczenia zawiodą.

Komunikacja klient – serwer

Wysyłając do serwera ważne dane musisz zadbać o to, by dla trzeciej osoby były niemożliwe do zmodyfikowania. Warto pomyśleć o szyfrowaniu i sumach kontrolnych – im więcej tym lepiej. Algorytmy szyfrujące dzielimy na symetryczne i asymetryczne. W przypadku szyfrowania po stronie klienta nie ma większej różnicy, z którego typu korzystasz. Jeżeli odpowiednio nie ukryjesz klucza przed osobą korzystającą z dekompilatora całe zabezpieczenie zda się na nic.

Najczęściej używane algorytmy szyfrującesymetryczne to AES, DES iBlowfish. Zazwyczaj są one mniej obciążające dla komputera niż algorytmy asymetryczne (np. RSA), dlatego powinieneś skupić się właśnie na nich. Najpopularniejsze algorytmy generujące sumy kontrolne to MD5 lub SHA-1.

Ukrywanie klucza

Musisz mieć na uwadze fakt, iż obfuscator nie zabezpieczy Twojego klucza (!). Dobry dekompilator może być w stanie wyciągnąć wartość zmiennej.  Najlepszym sposobem jest dynamiczne wstrzyknięcie klucza do generowanego po stronie serwera swfa. Niestety realia projektów rzadko kiedy pozwalają na poświęcenie znacznej ilości czasu na zabezpieczenia. Jeżeli ilość zer w budżecie Twojego projektu nie pozwala na tego typu wyszukane metody musisz ratować się półśrodkami.

Dobrym, prostym sposobem jest generowanie klucza z transformowanego MovieClipa. Na przykład:

private function getKey():void{
 
	keyDefinition = getDefinitionByName("keyGetter") a sClass;
	var keyClip:Sprite = new keyDefinition();
	keyClip.rotation = 14;
	var i :int = 16;
	while(i--){
		keyClip.rotation+= 17;
		key += (Math.round(keyClip.width+keyClip.height)%keyClip.rotation);
	}
}

Klucz ukryty w taki sposób jest już względnie bezpieczny, aczkolwiek wyciągnięcie go jest tylko kwestią większego nakładu pracy ze strony hackera.

Logowanie przebiegu gry

Bardzo dobrym pomysłem jest logowanie przebiegu gry – im więcej informacji zbierzesz tym łatwiej będzie Ci przesiać nieuczciwe wyniki. Możesz zapisywać wszystko – od ilości punktów w danym momencie rozgrywki, poprzez wykonywane  co jakiś czas kontrolne screeny, aż do zapisywania wszystkich pozycji kluczowych MovieClip’ów, ruchów myszką, kliknięć i uderzeń klawiszy. Im pełniejszy zapis gry tym trudniej będzie go podrobić. Dobrze jest poświęcić trochę czasu na optymalizację tej czynności: dowiedz się jakiego mniej więcej ruchu w swojej aplikacji możesz się spodziewać, jaki jest limit transferu, który możesz wykorzystać i dobierz do tego maksymalną wagę pliku, w którym będziesz przechowywać dane przebiegu gry.

Modyfikowanie pamięci

Furtką, o której często zapominają developerzy jest stosowanie przez nieuczciwych graczy programów typu Cheat Engine lub Memory Hacking Software. Programy te pozwalają na modyfikowanie pamieci procesu „w locie”. Dzięki tego typu oprogramowaniu hacker może znaleźć w pamięci wartość zmiennej odpowiadającą np. za uzyskane punkty lub czas i dowolnie ją zmodyfikować. Cały proces jest dziecinnie prosty i zajmuje kilkanaście sekund. W równie prosty sposób możesz zabezpieczyć się przed tego typu atakami:

package com.nobagames.utils{
 
	/**
	 * @author Andrzej Korolczuk
	*/
	public class ProtectedInt{
 
		private var _value :Number;
		private var shift:int;
 
		public function ProtectedInt(){
 
			shift = 10+int(Math.random()*990);
			_value = shift;
		}
 
		public function setZero():void{
 
			_value = shift;
		}
 
		public function add(value:int):void{
 
			var nextShift:int = 10+int(Math.random()*990);
			_value += nextShift-shift+value;
			shift = nextShift;
		}
 
		public function subtract(value:int):void{
 
			add(-value);
		}
 
		public function multiply(value:Number):void{
 
			var nextShift:int = 10+int(Math.random()*990);
			_value -= shift;
			_value *= value;
			_value += nextShift;
			shift = nextShift;
		}
 
		public function divide(value:Number):void{
 
			multiply(1/value);
		}
 
		public function getValue():int{
 
			return _value -shift;
		}
		public function toString():String{
 
			return String(getValue());
		}
	}
}

Klasa ta przesuwa wartość prawdziwej zmiennej o losową wartość uniemożliwiając wyszukanie jej wyżej wymienionymi programami. Po każdej operacji przesunięcie jest wyliczane ponownie, by jeszcze bardziej zmylić hackera. Jeżeli cały proces modyfikowania pamięci nie jest dla Ciebie jasny, obejrzyj na Youtube dowolny filmik z wyników wyszukiwania frazy „Cheat Engine”.

Programy te nie ograniczają się jedynie do modyfikowania pamięci. Używając ich można również spowolnić lub przyspieszyć proces przeglądarki, co może być wykorzystywane na przykład do wydłużenia czasu na reakcję w grę zręcznościowej. Najlepszą obroną na tego typu sztuczki jest porównanie czasu, który upłynął po stronie serwera z czasem, który upłynął po stronie klienta.

Boty

Niedawno spotkałem się z przypadkiem, w którym osoba biorąca udział w konkursie napisała program w C#, który imitował odkrywanie kart w grze typu Memo, korzystając z Windows API. Po odsłonięciu wszystkich kart po kolei program wiedział, gdzie dokładnie znajdują się kolejne pary i w błyskawicznym tempie odkrywał je.

Stanowczo jest to najbardziej pracochłonny sposób na nieuczciwe rywalizowanie, ale też jest najcięższy do wykrycia. Analizując logi lub pliki przebiegu gry warto zwrócić uwagę na powtarzające się interwały zdarzeń, sztuczne, mechaniczne ruchy myszką itp.

Inne

Dobrym pomysłem jest zmienianie jakiegoś detalu w swoim SWF’ie. Może być to kolor przycisku lub zmienna wysyłana na serwer. Dzięki temu, jeżeli obfuscator zawiedzie i hackerowi uda się podmienić SWFa na swoją wersję możesz być w stanie udowodnić mu, że oszukiwał. Najlepszym pomysłem jest wprowadzanie takiej zmiany codziennie. Prawdopodobieństwo, że potencjalny haker będzie sprawdzał codziennie czy plik na serwerze się nie zmienił jest raczej znikome.

Podsumowanie

Żadna kombinacja opisanych przeze mnie zabezpieczeń nie gwarantuje stuprocentowej pewności, jeżeli logika działania aplikacji znajduje się w pliku SWF. Prawdopodobnie też istnieje wiele innych sposobów, wykorzystywanych przez hackerów, o których nawet nie słyszałem. Jedynym sposobem dającym pełne bezpieczeństwo jest cienki klient i najprawdopodobniej wraz z kolejnymi wersjami Flash Playera nic się w tym temacie nie zmieni.