[Pytanie] HShield w WarRock

[Lukazuki]

Dzisiaj bawiłem się programem HHD Software Hex Edytor na pliku warrock.exe i tak sobie w nim coś szukałem i znalazłem

 

 

Próbowałem pozbyć się z warrock.exe ścian a mianowicie 2 plików StaticObject.dat i Occlusion.dat usunąłem je wchodzę do gry loguje się i nagle wyskakuje komunikat że HShield wykrył niezgodność i konto zostaje zablokowane i tu jest mój problem jak unieszkodliwić HS

 

Znalazłem ten tekst odpowiedzialny za włączanie HS próbuje coś tam z nim zrobić zapisuje ale potem jak chce wejść do gry to się nie da

 

Jak ktoś się na tym zna to niech napisze co usunąć z tego tekstu żeby się HS nie włączył

[Propagandhi]

Jak ktoś się na tym zna to niech napisze co usunąć z tego tekstu żeby się HS nie włączył

 

Obawiam się, że samym edytowaniem pliku niewiele zdziałasz. Ale to co znalazłeś na początku, to zdaje się ścieżka do głównej biblioteki HShield - EhSvc.dll. Zamieszczam link z dyskusją ludzi z Game Deception o bypassowaniu HShield. Jest tam trochę przydatnych informacji od osób, które się już trochę ścierały z tym systemem anty hakerskim. W skrócie wyjaśnię o czym mowa w pierwszym poście. Gość ustalił, że EhSvc.dll to plik interfejsu HS, jest bardzo dobrze zabezpieczony i trudno się do niego dobrać, ale ładuje też inne pliki z funkcjami które przejmują komunikaty od innych funkcji nadpisujących i czytających pamięć (w konsekwencji je blokuje). W grze dostał komunikat o wykryciu jakiegoś hacka. Postanowił poszukać stringa z tym komunikatem w kodzie programu. Wcześniej jednak musiał zdekompresować plik exe gry za pomocą kompresora UPX. Teraz otworzył exe'ka za pomocą disassemblera IDA Pro i wśród strigów wyszukał swój komunikat. Szukając źródła tego komunikatu poprzez różne referencje w assemblerze dochodzi do funkcji JG, którą nadpisuje dwoma NOP'ami i tym samym pacyfikuje HackShield. Znając adres funkcji JG można wstawić w swoim hacku kod, który nadpisze ją NOP'ami. Ktoś już coś podobnego prezentował na tym forum. Nie wiem na ile aktualny to sposób, ale chciałem tylko pokazać, że takie proste do końca to nie jest.

 

 

Jak znajdę jeszcze jakieś ciekawe dyskusje na ten temat, to dołączę linki do tego tematu.

 

@edit: Sprawdziłem programikiem o nazwie PEiD czym to jest pakowane. Wygląda na to, że exe jest wolny od tego typu zabiegów, z kolei EhSvc.dll zabezpieczona jest ASProtect SKE w wersji 2.1, lub wyższej. Na dobrą sprawę część stringów da się z exe'ka wyłowić, ale większość jest zaszyfrowana (prawdopodobnie xor'em) i bez klucza nie sposób ich odczytać.

[lukaszek91]

Może wiecie już coś nowego na ten temat hackshield w warrock jak się go pozbyć lub tez jak go zablokować Prosiłbym o odpowiedz jeśli ktos coś by wiedzial żeby to wytłumaczyl krok po kroku z góry dzieki

[Propagandhi]

Próbowałem już kilku rzeczy z większym, lub mniejszym sukcesem. Udało mi się całkowicie zablokować komunikaty o wykrytym hacku, ale po zalogowaniu do gry w kilka minut rozłącza mnie z serwerem (bez bana/kicka na koncie). I tu przydałaby się Wasza pomoc i inwencja, bo próby obejścia tych zabezpieczeń są dość czasochłonne. Po krotce wyjaśnię co do tej pory zmajstrowałem. Korzystałem z darmowej wersji debuggera Ida Pro i zwykłego CE.

Zacząłem od komunikatów typu "Running game hack-tool detected!". Jest ich całkiem sporo (dotyczą różnych typów narzędzi do hackowania) i są rozsypane w kilku procedurach. Blokowanie tego nie przyniosło skutku, bo w grze po jakimś czasie pojawiał się inny komunikat "Modification to memory is detected!"- w efekcie kick/ban. Samego stringa z tym komunikatem nie mogłem znaleźć, ale znalazłem caption okna: "Hack Detected!". pojawia się ono w wszystkich komunikatach o hacku/debuggerze itd. W Ida szukacie tego w oknie Names.

 

 

.rdata:008D45AC aHackDetected db 'Hack Detected!',0 ; DATA XREF: WinMain(x,x,x,x)+305o

 

Ma referencje w WinMain(x,x,x,x)+305o i jak klikniemy w nią, to wygląda tak:

 

.text:004D7FE1 loc_4D7FE1: ; CODE XREF: WinMain(x,x,x,x)+2DEj

.text:004D7FE1 push 3E8h ; unsigned __int32

.text:004D7FE6 call __sleep

.text:004D7FEB mov ecx, hWnd

.text:004D7FF1 add esp, 4

.text:004D7FF4 push ebx ; uType

.text:004D7FF5 push offset aHackDetected ; "Hack Detected!" //nasz komunikat

.text:004D7FFA push esi ; lpText

.text:004D7FFB push ecx ; hWnd

.text:004D7FFC call ds:MessageBoxA

.text:004D8002 push esi ; void *

.text:004D8003 call j_j__free

.text:004D8008 add esp, 4

 

Z kolei do tej lokacji referuje CODE XREF: WinMain(x,x,x,x)+2DEj:

 

.text:004D7FBC loc_4D7FBC: ; CODE XREF: WinMain(x,x,x,x)+2BEj

.text:004D7FBC push ebx

.text:004D7FBD mov ecx, offset unk_1BA2D58

.text:004D7FC2 call sub_5C9920

.text:004D7FC7 mov eax, dword_C13440

.text:004D7FCC cmp eax, ebx

.text:004D7FCE jz short loc_4D7FE1

.text:004D7FD0 push esi

.text:004D7FD1 push 29Ah

.text:004D7FD6 lea ecx, [eax+36280h]

.text:004D7FDC call sub_46AFA0

 

Widać teraz, ze skacze do pierwszej lokacji za pomocą jz (jump if zero), ale szukamy kolejnej referencji - CODE XREF: WinMain(x,x,x,x)+2BEj:

 

.text:004D7FA0 loc_4D7FA0: ; CODE XREF: WinMain(x,x,x,x)+2A8j

.text:004D7FA0 ; WinMain(x,x,x,x)+2C8j

.text:004D7FA0 mov ecx, offset unk_1BA4068

.text:004D7FA5 call sub_5C9320

.text:004D7FAA mov esi, eax

.text:004D7FAC cmp esi, ebx

.text:004D7FAE jnz short loc_4D7FBC

.text:004D7FB0 call sub_427040

.text:004D7FB5 test ax, ax

.text:004D7FB8 jle short loc_4D7FA0

.text:004D7FBA jmp short loc_4D800B

 

W tej dopiero zacząłem coś działać. Chodzi konkretnie o skok jnz short loc_4D7FBC pod adresem 004D7FAE. Jak klikniecie na to i przejdziecie do okienka Hex-View, to zobaczycie, że zajmuje dwa bajty: 75 0C. Najprostszy sposób, żeby unieszkodliwić ten skok to nadpisać go dwoma nopami (bajty 90 90). W zasadzie to by było wszystko, ale ponieważ mnie rozłączało próbowałem jeszcze paru innych rzeczy. Poniżej objaśnię szybko jakich. Pomyślałem, że rozłącza mnie ponieważ unieszkodliwiając skok wpłynąłem na wartości w rejestrach procesora.

 

.text:004D7FA5 call sub_5C9320

.text:004D7FAA mov esi, eax

.text:004D7FAC cmp esi, ebx

.text:004D7FAE jnz short loc_4D7FBC

 

Na ile doczytałem o assemblerze pierwsza linijka wywołuje odpowiednią procedurę pod adresem 5C9320. "mov esi, eax" przenosi wartości z rejestru eax do esi. "cmp esi, ebx" Porównuje wartości z esi i ebx a jnz w zależności od tego, czy są nierówne (jump if not zero = jump if not equal) skacze do loc_4D7FBC. Pomyślałem, że zanim dojdzie do porównania wyzeruje te dwa rejestry, ale ponieważ nie wcisnę tego w tej lokacji, to muszę zrobić coś jak code cave. Jak zanopowałem skok, to w grze już działałem za pomocą CE. Pierwsze co musimy zrobić, to zaalokować z 30 bajtów na "jaskinie" i zerowanie rejestrów. W CE, to będzie w menu pod "Alocate memory". W CE zdaje się funkcja sama wybiera, gdzie zaalokuje pamięć. Mnie zależało na tym, żeby samemu wybrac odpowiednie miejsce i użyłem funkcji VirtualAlloc.

 

VirtualAlloc(

(LPVOID)0x058F0000, // pointer do mojej lokacji - gdyby napisac null, to funkcja sama by wybrała

30, // moje 30 bajtów na code cave

MEM_COMMIT | MEM_RESERVE, // typ alokacji

PAGE_EXECUTE_READWRITE); // typ ochrony zaalokowanej pamięci

 

Ważny jest typ alokacji. Na początku użyłem tylko MEM_COMMIT, ale jeśli strona pamięci nie jest wcześniej zarezerwowana, to funkcja zwróci wartość 0, czyli błąd. PAGE_EXECUTE_READWRITE - to myśle jest akurat jasne. Dodam tylko, że funkcja do zmiany typu ochrony nazywa się VirtualProtect.

 

Jak już zaalokowałem pamięć, to w CE zacząłem pisać jaskinie. To ważne w jakiej kolejności, bo jak skoczycie z kodu gry w pustą przestrzeń, to skraszujecie program.

 

Pierwsza wersja wyglądała tak:

 

058F0000 - e8 1b 93 cd fa - call 005c9320

058F0005 - 31 c0 - xor eax,eax

058F0007 - 31 db - xor ebx,ebx

058F0009 - 90 - nop

058F000A - 90 - nop

058F000B - 90 - nop

058F000C - 90 - nop

058F000D - 90 - nop

058F000E - 90 - nop

058F000F - 90 - nop

058F0010 - 90 - nop

058F0011 - 90 - nop

058F0012 - 90 - nop

058F0013 - 90 - nop

058F0014 - 90 - nop

058F0015 - 90 - nop

058F0016 - 90 - nop

058F0017 - 90 - nop

058F0018 - 90 - nop

058F0019 - e9 8c 7f be fa - jmp 004d7faa

 

I teraz dopiero skok z pierwotnej lokacji:

 

004D7FA5 - e9 56 80 41 05 - jmp 058f0000 //zamiast call 005c9320 (akurat 5 bajtów zajmował)

 

xor'y zerują rejestry, dlatego zawsze są równe i jnz nigdy nie będzie spełnione - nie wywali komunikatu

 

O ile bajty xor'ów się nie zmienią, to bajty jumpów będą inne w zależności dokąd skaczą.

Zamiast xorów zrobiłem jeszcze coś takiego:

 

058F0009 - 8b d8 - mov ebx,eax

 

Przenosi eax do ebx, dlatego teoretycznie przy porównaniu zawsze powinny być równe.

 

Skoro mam statyczną alokacje i znam bajty, to można to wmontować do hacka. Z użyciem biblioteki z którą pracowałem przy wstrzykiwaniu dll'ek wygląda to tak:

 

int wynbajt;

 

byte[] bajtbypass3 = { 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,

0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,

0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90 };

 

byte[] bajtcc1 = { 0xe8, 0x1b, 0x93, 0xcd, 0xfa };//call

byte[] bajtcc2 = { 0x31, 0xc0 };//xor

byte[] bajtcc3 = { 0x31, 0xdb };//xor

byte[] bajtcc4 = { 0xe9, 0x8c, 0x7f, 0xbe, 0xfa };

byte[] bajtjmp = { 0xe9, 0x56, 0x80, 0x41, 0x05 };

 

edytpam.ZapiszPamiec((IntPtr)0x058f0000, bajtbypass3, out wynbajt); //nop code cave

edytpam.ZapiszPamiec((IntPtr)0x058f0000, bajtcc1, out wynbajt); //call

edytpam.ZapiszPamiec((IntPtr)0x058f0005, bajtcc2, out wynbajt); //xor

edytpam.ZapiszPamiec((IntPtr)0x058f0007, bajtcc3, out wynbajt); //xor

edytpam.ZapiszPamiec((IntPtr)0x058f0019, bajtcc4, out wynbajt); //jmp cc

edytpam.ZapiszPamiec((IntPtr)0x004D7FA5, bajtjmp, out wynbajt); //jmp src

 

To tylko przykład, bo identyczną robotę zrobi nopowanie skoku w lokacji:

 

int wynbajt;

byte[] bajtbypass2 = { 0x90, 0x90 }; //75 0C

edytpam.ZapiszPamiec((IntPtr)0x4D7FAE, bajtbypass2, out wynbajt);

 

To tyle na razie. Pozostaje jeszcze unieszkodliwić rozłączanie z serwerem. Szukałem komunikatu "Connection terminated from server" ale nie znalazłem. Wyłowiłem z kolei caption okna ("Message"), choć nawet nie jestem pewien, czy to to. Jak znajdę chwile, to sprawdzę i wy też możecie pokombinować.

 

Edit1: String się znalazł w pliku ..\WarRock\Data\textdata_eng.lua i parę innych też. Wygląda to tak:

m124 = "Connection terminated from server"

Jak poszukacie stringa "m124" to znajdziecie procedurę, która wywala ten komunikat.

 

Edit2: Znalazłem jeszcze jedną ciekawą rzecz. N1ghtmare swego czasu podesłał mi info o wtyczce do Olly - olly dump. Prawdopodobnie działa to na tej zasadzie, że w czasie debugowania zrzuca całą pamięć i zapisuje w formie pliku exe. Ma to spore znaczenie, bo wielu rzeczy przy dezasemblowaniu exe'ka nie widać i ładują się dopiero po jego opaleniu do pamięci. Może ktoś już zauważył, ale ciężko do WarRock.exe podczepić jakikolwiek debugger. Problem pojawia się nawet, gdy nie podczepiamy się pod uruchomiony już proces a odpalamy go w debuggerze. Doszedłem do wniosku, że exe'c musi być uruchamiany z jakimiś parametrami i zabrałem się za plik WRUpdater.exe. Odpala on WarRock.exe za pomocą funkcji CreateProcessA z parametrem %s. Ok, ktoś spyta co nam to daje? W większości debuggerów powinno dać się ustawić ten parametr przed samym debugowaniem i zrobić kompletny obraz pamięci. W IDA Pro takim odpowiednikiem wtyczki z Olly powinno być "Take memory snapshot" (W menu "Debugger"). Działa to trochę inaczej, bo nie tworzy exe'ca ale całość zrzuconej pamięci dodaje do bazy danych o pliku i analizuje nowy kod.

Można to też zastosować do bezpośredniego odpalania gry bez update. Chyba da się to nawet zrobić za pomocą zwykłego skrótu, ale na szybko zmontowałem aplikacje, która robi dokładnie to samo co WRUpdater.exe:

 

char szCmdLine[] = "WarRock.exe %s"; 
                 STARTUPINFO Si;
                 PROCESS_INFORMATION Pi;
                 ZeroMemory( &Si, sizeof(Si) );
                 Si.cb = sizeof(Si);
                 ZeroMemory( Π, sizeof(Pi) );
                 CreateProcess(NULL, szCmdLine, NULL, NULL, FALSE, 0, NULL, NULL, &Si, Π);

 

Popracuje jeszcze nad tym i niebawem napisze, co z tego wynikło.