Witam!!
Chciałbym zamieścić wam pewien poradnik, znalazłem go niedawno w Wielkiej Księdze Tipsów CDA - Lato 2002.
Napisał go Draco. Może komuś się przyda!!
Jeśli macie jakieś zastrzeżenie, znaleźliście błędy czy co piszcie!!
Jak (wy)grać gdy, nie ma tipsów i trainerów?
Jak skutecznie oszukać grę?
Jak włamać się do gry i zmusić ją do posłuchu?
Linki do programu:
http://www.piorunek.pl/prog/pliki/pliki/dn151.zip
Wstęp do wstępu
Wbrew pozorom niniejszy poradnik nie ma NIC wspólnego z prawdziwym hakingiem, aczkolwiek jeśli jesteś zainteresowany nauką grzebania w "bebechach" gry, celem ułatwienia sobie życia, to dobrze trafiłeś! Tu będzie mowa właśnie o tym! A jeśli zamierzasz tylko grać i masz wszystko inne w głębokim poważaniu i w życiu nie uruchomiłeś nawet żadnego programu użytkowego - mimo wszystko przeczytaj ten akapit, a nie pożałujesz. Przewrócić stronę zawsze zdążysz, te kilka(dzjesiąt) sekund cię nie zbawi. Ale jeśli uważasz, że interesuje cię tylko i wyłącznie granie i nie masz ambicji by to sobie ułatwić i robić coś więcej niż "pykanie" w rozmaitego typu gierek... to powiedzmy sobie tutaj "do widzenia". Ale nie narzekaj później, że nie możesz ukończyć tej czy innej gry. Gdybyś doczytał do końca, nie miałbyś takich problemów. Decyzja należy do Ciebie.
Draco
Wstęp właściwy
Graczy można podzielić na dwie kategorie. Ci pierwsi grają długo i uczciwie, z mozołem pokonując kolejne / gry. Druga kategoria to ludzie, którzy i owszem grają... ale tylko w gry w ten czy inny sposób "ulepszone” tak przez siebie, jak i innych spryciarzy (trainery, tisy itp.). Ci pierwsi na widok tych drugich pukają się w czoło, mówią coś o uczciwości, przyjemności płynącej z długotrwałej gry, radości z przejścia kolejnego etapu, 3 czym dodają z wyższością "wy tego nigdy nie zrozumiecie". Tamci rewanżują się z kolei przycinkami do ości zmarnowanego nad grą czasu, podczas mozol-i przechodzenia po raz 356 przez ten sam etap, wodzenia graczy za nos przez programistów itp.
Cóż - obie strony mają rację. Granie ma wszak dawać przyjemność i relaksować. Tyle tylko, że największą przyjemnością i relaksem dla pierwszej grupy jest uczciwe ukończenie gry, zaś dla "włamywaczy" nie ma większej radości niż namieszanie w jej parametrach i zmuszenie do działania wedle ich zasad. Mniejsza teraz o to czy jest to fair, czy nie fair. Zakładam, że sam nieraz, drogi graczu, zgrzytałeś zębami nad tą czy inną grą, w j beznadziejnie utknąłeś w miejscu nie do przejścia. A tu ani tipsów, ani trainerów... Dlatego - jeśli tylko chcesz - spróbuję wprowadzić cię do "przedszkola włamywacza". Po przeczytaniu tego poradnika powinieneś umieć skutecznie włamać się przynajmniej do części.
A czy będziesz chciał wykorzystać te umiejętności w praktyce - to już twoja sprawa. Osoby, które posiadają i choćby minimalną wiedzę na ten temat (o programistach nawet nie wspominając), ostrzegam, że wykład adresowany jest do zupełnie "zielonych" graczy, i będzie on bardzo "łopatologiczny" i będą w nim Omawiane rzeczy bardzo oczywiste, w sposób niekiedy potwornie uproszczony. Ale to nie jest lekcja informatyki...
Let's go!
Aby zostać włamywaczem, potrzebujesz niewiele: odrobiny chęci i dobrej woli, znajomości matematyki w zakresie tabliczki mnożenia, programu typu menadżer plików - np. DOS Nawigator [*] (jest na Cover CD w katalogu Tipsomaniak w Bonusie) lub jakiś inny manager plików zbliżony do DN charakterem, kartki papieru, czegoś do pisania... no i gry do eksperymentów. Zajmiemy się dziś najprostszym "włamywactwem", to jest modyfikacją zgrywek (save-game'ów). Sprawa jest - wbrew pozorom - prosta jak drut. Wystarczy tylko znać podstawowe zasady... Zabiegi są tak naprawdę równie trudne jak stuknięcie młotkiem w rurę, a cala sztuka (wcale nie tak skomplikowana) polega na tym, by wiedzieć GDZIE i JAK MOCNO stuknąć, l tego postaram się was nauczyć... Aby było łatwiej, poćwiczymy na jakiejś grze, np. Heroes Might & Magie 2. Póki co uruchomcie jednak nie grę - a wspomnianego DOS Navigatora... Gotowi? No to zaczynamy!
Ale zanim zaczniemy babrać się w komputerowych bebechach gry, musicie wysłuchać małego wykładu. W naszej zabawie będziemy bowiem stykać się ze sposobem zapisu wartości liczb, zwanym "systemem szesnastkowym" (heksadecymalnym). Różni się on od używanego przez nas systemu dziesiętnego tym, że wykorzystuje zamiast dziesięciu aż szesnaście cyfr do zapisu wartości liczby. Czemu tak? M.in. dlatego, że komputer woli heksy od systemu 10-tnego [**] i to musi starczyć za wszelkie argumenty, bo go nie przekonacie, by liczył "po ludzku". Mądrzejszy musi ustąpić...
No dobra. W systemie dziesiętnym po cyfrze "9" następuje liczba "10" (składająca się już z dwóch cyfr - 1 i 0), w systemie szesnastkowym zaś liczbę "1 0" zapisujemy jako "A" (a właściwie OA) . 1 1 to OB, 1 2 = OC, 1 3 = OD, 1 4 = OE, 14 = OF, zaś 16=10, 17 = 11 itp. Na początku może to być bardzo mylące i męczące dla graczy, dla których 1 0 to 1 0, a nie jakieś tam głupie OA! Aby nie męczyć się nieustannym przeliczaniem liczb dziesiętnych na heksadecymalne, możemy używać kalkulatora w DOS Nawigatorze (naciśnij CTRL-F6). Wpisując dowolną liczbę dziesiętną, w okienku HEX widzimy jej wersję heksadecymalną. Np. wpiszmy 45.454. Powinniśmy uzyskać liczbę B18E. Z kolei wpisując dowolną liczbę w systemie szesnastkowym (UWAGA: MUSI być poprzedzona symbolem dolara $, by komputer wiedział, że chodzi nam o heksy... bo przecież wartość np. 1234 może być liczbą zapisaną tak w systemie dziesiętnym, jak i szesnastkowym; znak $ oznacza natomiast "hej, to są heksy!"), np. $ABCD, uzyskamy wersję dziesiętną (43.981). Radzę to poćwiczyć!
Krótki egzamin?
1. Ile to jest (w heksach) 25000?
2. Przeliczcie wartość $DDAA na system dziesiętny.
Czemu o tym piszę? Otóż wszystkie liczby, z jakimi zetkniemy się podczas edycji save-game'u, to liczby heksadecymalne. Natomiast grając w dowolną grę, mamy na ekranie wszystkie parametry postaci, pojazdów itp. podawane w systemie dziesiętnym. Dlatego musimy nauczyć się przeliczać znalezione tam wartości na heksy. Np. chcąc podrasować grubość pancerza swego czołgu (powiedzmy 100 mm), musimy w save szukać wartości 64 (czyli 100 zapisane w systemie heksadecy-malnym). Teraz zmieniamy na np. 255 (naturalnie po przeliczeniu na heksy) i zastępujemy pierwotną wartość, l już nikt nam nie podskoczy. Proste, prawda? Przynajmniej wteorii. Ale praktyka jest... jeszcze prostsza, uwierzcie mi - a wkrótce sami to przyznacie!
Teraz uruchomcie Heroes Might & Magie 2. Zacznijmy grać w kampanię. Rozpoczynamy pierwszą misję, l na początku zastanówmy się, co chcemy zmienić w naszej grze? Podstawową bolączką gracza jest zbyt mata ilość pieniędzy. Zatem spróbujmy powiększyć nasz majątek
Jak? Zapiszmy sobie na razie ilość gotówki, jaką dysponujemy: 12.000 szt. złota. Po czym dokonujemy zgrania stanu gry i na razie żegnamy się z programem. Interesuje nas tylko sam plik save. A znajdziecie go w katalogu, jaki założył na twardzielu instalator HMM2, w podkatalogu GAMES, pod nadaną mu nazwą i z rozszerzeniem GMC. Znaleźć plik save jest zresztą prosto, ponieważ zwykle albo znajduje się on w jakimś katalogu typu SAVE, albo nazywa się savegame1 (2,3,4 itp.), albo - co jeszcze bardziej ułatwia nam robotę - ma nazwę, jaką nadaliśmy naszemu save podczas zgrywania stanu gry (np. Bolekl).
Ponownie uruchamiamy DN. Odczytujemy ten plik za pomocą klawisza F3 (spod wspomnianego Dos Navigatora - gdy stosujesz inny program, sam musisz "obcykać" klawiszologię). Nie przejmujcie się tym, co ujrzycie na ekranie. Ot, jakaś tam "kasza". Teraz klawiszem F4 (konwersja ASCII/Hex) zamieniamy tę kaszę na symbole ASCII i wartości heksadecymalne. Jeśli zrobiliście wszystko poprawnie, na ekranie mace (kolejno od lewej): słupek z ośmiocyfrowymi liczbami (adresami)-00000010, 00000020 itp. Co to jest itp., dowiecie się w swoim czasie, w tymże poradniku. Pośrodku widzicie heksadecymalne wartości kolejnych bajtów (przedstawiane jako zespoły składające się z kombinacji dwóch cyfr, liter lub cyfr i liter, np. 50 OA BC 00 00 DF 1 E). Te z kolei oddzielone są linią od wyświetlanych wartości ASCII. Jak znaleźć tu potrzebny nam stan gotówki?
1. Przeliczamy najpierw 12.000 na heksy. Powinniśmy uzyskać wartość 2EEO.
2. Teraz należy odszukać tę wartość w tysiącach cyfr i liczb, składających się na nasz save. Jak to osiągnąć?
3. Wybieramy klawisz F7 (Search) i wpisujemy w oknie HEX wartość... jaką? Wydaje się to oczywiste - naturalnie: 2EEO. ALE... to byłoby za proste. Z pewnych przyczyn (które w tej chwili są nieistotne) wartość tę dzielimy najpierw na dwuelementowe zespoły, czyli bajty: 2E i EO. Teraz dopiero wpisujemy w okno HEX tę wartość, tyle że w ODWROTNEJ kolejności: E02E. Komputer powinien odszukać wszystkie wartości E02E w całym save'ie. Jeśli jest tylko jedna taka liczba, to wszystko jest proste. Tu właśnie zapisany jest stan gotówki!
Ale co będzie, jeśli uzyskamy dużo więcej adresów, w których znajdziemy taką wartość? Co wtedy? Która liczba jest tą, której szukamy? Jak ją rozpoznać? Cóż, wtedy trzeba poeksperymentować. Zapisujemy wszystkie adresy (tj. numery tych linii, w których występują takie wartości, by potem je łatwiej odnaleźć), w których występuje ciąg EO 2E, wracamy do gry, i spokojnie czekamy jeden dzień w kampanii - stan naszej kasy zwiększa się o 1000, czyli mamy już na koncie 13.000. Znów zgrywamy stan gry, przeliczamy 13000 na heksy (co da nam 32C8) i tym razem szukamy tej wartości, naturalnie również zapisanej w odwrotny sposób (czyli C832). Jeśli w jednym ze spisanych adresów, gdzie przedtem znajdowała się wartość EO 2E znajdziemy teraz C8 32 to mamy 100% pewności, że właśnie w tym miejscu komputer zapisuje stan gotówki! Teraz więc wystarczy zamienić tę wartość na jakąkolwiek inną, wyższą (np. wpisując FF f f). Jak to zrobić? Po prostu ustaw kursor na danej komórce i wpisz tam nową wartość!
4. Teraz zgrywamy plik (gdy wychodzimy z Dos Navigatora, komputer zapyta czy zapisać zmiany - naturalnie tak!), uruchamiamy grę, wczytujemy save... i widzimy, że stan gotówki zwiększył się radykalnie. Jeśli wpisaliśmy FF FF, mamy teraz na koncie 65.535 sztuk złota (bo FF FF w heksach to 65.535 w systemie dziesiętnym, prawda?). Sporo... ale jednak nie za dużo. Wracamy więc do edycji save-game'a. Odnajdujemy wcześniej wpisaną wartość FF FF i zmieniamy ją na FF FF FF (ostatnie FF wpisujemy w następną wolną po FF FF komórkę). To da nam... (przeliczcie sobie...) 16.777.215 złota. Powinno wystarczyć! ;-).
l nie musicie nawet zbytnio szukać. Cash jest w tej grze ZAWSZE w ciągu komórek zaczynających się od adresu 04AF. Użyjcie (w trybie edycji save gamę) klawisza F5 (GOTO), wpiszcie ten adres... i już jesteście w domu. Wystarczy teraz wstukać tam wymaganą ilość gotówki. Nie radzę jednak (z przyczyn, które omówię w innym odcinku) wpisywać tam więcej jak FF FF FF!
Ze sporą gotówka, możemy bez problemu zakupić na targu dowolną ilość dowolnych minerałów. Ale powiedzmy, że jesteśmy za leniwi i nie chce się nam handlować. Chcemy za to pobawić się w edycję surowców. Nic prostszego. Spisujemy po prostu wartości kolejnych minerałów z okna informacyjnego w grze (drewno = 30, rtęć = 10, kamienie = 30, siarka = 10, kryształy = 10, klejnoty = 10). Przeliczamy je na heksy (30=14, 10 = OA). Teraz wystarczy poszukać ciągu bajtów 14 OA 14 OA OA OA. l co? Hm. Nie ma czegoś takiego. Dlaczego? Pomyślmy... w jednej komórce możemy zapisać maks. wartość FF, co daje nam w systemie dziesiętnym liczbę 255. Trochę mało - tych minerałów na pewno jest w grze dużo więcej. Może więc do zapisu ich wartości komputer rezerwuje na wszelki wypadek DWIE KOLEJNE komórki? Na początku, ponieważ dysponujemy małą ilością minerałów, są one puste, tzn. wypełnione zerami. Zatem powinniśmy poszukać ciągu komórek 14 00 OA 0014 00 itp. Nadal nic? To może na każdy minerał rezerwowane są trzy kolejne komórki, tj. trzeba szukać wartości 14 00 00 OA 00 00 14? Otóż to! Mamy taki adres!!! Teraz wystarczy więc wpisać odpowiednie wartości (ale nie więcej niż FF FF dla każdego surowca) i po kłopocie! Znów was wyręczyłem w poszukiwaniach i oto adresy, w których mieszczą się wartości poszczególnych minerałów: 0497 = drewno, 049B = rtęć, 04AO = kamienie, 04A3 = siarka, 04A7 = kryształy, 04AB = klejnoty.
Tyle na początek. Spróbujcie ew. poćwiczyć na innych
grach! Tu jednak ostrzegam, że:
-> nie każdą grę da się oszukać w taki sposób;
-> nie wiecie jeszcze wielu rzeczy, więc nie martwcie
się, gdy na początku się wam nie uda
-> zatem nie pękajcie gdy coś idzie nie tak!
UWAGA: przed rozpoczęciem jakichkolwiek manipulacji na save-game wykonaj wcześniej jego kopię bezpieczeństwa!!! Ważne!
Teraz chciałbym zrobić małą dygresję i opowiedzieć wam o niebezpieczeństwach związanych z włamywaniem się do save'ów gier. Efektem mieszania w nich często jest zawieszanie się gier lub - co gorsza - jakieś dziwne "przekręty" podczas rozgrywki (np. niespodziewane i na pozór bezsensowne zmiany rozmaitych parametrów - nawet tych, których nie modyfikowaliśmy!), niekiedy pojawiające się dopiero po jakimś czasie od naszej ingerencji. Czemu się tak dzieje? Zawieszanie może być naturalnie skutkiem wpisania jakiejś wartości do nieodpowiedniej komórki (myślimy, że modyfikujemy stan kasy, a okazuje się, że 'skaszaniliśmy* właśnie jakiś Bardzo Ważny Element Gry). Ale załóżmy, że mamy 200% pewności, iż dobrze zidentyfikowaliśmy dany adres. Czemu więc gra się zawiesza? Omówmy to na fikcyjnym przykładzie: w jakiejś grze RPG podkręcamy np. ilość energii magicznej (mana) z powiedzmy $2A [czyli 42] na miłe oczom $FF [255]. Wszystko potem gra, jesteśmy napakowani maną jak Arnold sterydami, świat jest piękny... Po czym np. napotykamy bandę orków, smażymy ich w pierwszym starciu jakimś fireballem na skwarki, następuje koniec tury... O, fuck!! Albo gra się kaszani, albo okazuje się, że ilość naszej many spada niespodziewanie do np. 03, a przy okazji zmieniła się np. inteligencja postaci (i to na gorsze). Co się dzieje?! Ano - zawiniła tu "chciwość" gracza i brak orientacji w informatycznym abecadle.
Zanim wyjaśnię to dokładniej, na chwilkę skończmy z tymi bardzo teoretycznymi rozważaniami - dla relaksu pora na nieco konkretniejsze informacje. W poprzednim artykule pisałem, że po przeliczeniu wartości dziesiętnej na heksy, jeśli zawiera się więcej niż w dwu elementach, dzielimy ją na dwucyfrowe wartości, celem dalszej obróbki (np. 3ACD to 3A CD). Tu od razu ktoś może mieć wątpliwość: "no dobra, ale ja otrzymałem wartość składającą się tylko z 3 cyfr, np. 14A. l jak to podzielić?". Otóż zasada jest taka, że w naszych rozważaniach NIE MA czegoś takiego jak liczba składająca się z nieparzystej ilości elementów. Co więc zrobić z bezczelnie nieparzysto-cyfrową wartością 14A? (A właściwie $14A, ponieważ zapamiętajcie raz na zawsze, że pisząc jakiekolwiek wartości heksadecymalne, poprzedzamy je znakiem $, by odróżnić je od wartości zapisanych w systemie 10-tnym.) Jak poradzić sobie z liczbą $14A? Rada jest jedna: w przypadku liczb heksadecymalnych, składających się z nieparzystej ilości cyfr (i liter), dopisujemy zero na początku ciągu. Czyli nie mamy już $14A, a $014A. Nie mamy $ABCDE - istnieje dla nas tylko $OABCDE! Nie ma $01B - jest $001 B! Teraz podział liczb na dwuelementowe kawałki przestał być problemem, prawda?
Wracamy do teorii! (Musicie ją opanować, choćby w minimalnym stopniu). Jak nasz PC-et zapisuje liczby? Otóż, jak wiadomo, zapisuje je w bajtach. W systemie heksadecymalnym w jednym bajcie można maksymalnie wpisać wartość $FF (255). A co będzie, jeśli trzeba zapisać wyższą wartość? Wykorzystuje się do tego kolejne (sąsiednie) bajty i stąd, by zapisać wartość 43.981 (w heksie $ABCD) PC zajmuje dwie sąsiednie komórki, wpisując do nich kolejno CD i AB (a czemu tak od końca - o tym później, by nie zamącić wam w głowach). Otóż załóżmy teraz, że w omawianej, hipotetycznej grze RPG maksymalna ilość many, jaką przewidział scenarzysta dla najbardziej nawet zaawansowanych postaci, miała nie przewyższać 100 (czyli $64 w heksach).
Programista zatem zarezerwował tylko jedną komórkę na zapis wartości tego parametru. A teraz taki początkujący 'haker1 wstawia tam FF (albo i FF FF). Po wpisaniu FF FF gra się natychmiast zawiesza. Why? Bo sąsiednia komórka mogła być odpowiedzialna za np. ogólną kondycję danej postaci (gdzie przewidziano wartości O -zdrowy, 1 - ranny, 2 - martwy) i wpisanie FF, a wiec wartości nie przewidzianej przez autora kodu, powoduję "ogłupienie" komputera, który nie wie, jak to zinterpretować... a to oznacza najczęściej zawieszenie się gry. Dobra, to jest zrozumiałe. Ale czemu dzieją się takie cuda z wartościami many i inteligencji? No cóż, eto wsio very proste;-). Gracz zwyczajnie... "przekręcił licznik"! Po usmażeniu orków komputer dodał nam punktów doświadczenia, a to z kolei owocuje zwiększeniem liczby many o np. 10 pkt. Komputer dodaje więc do $FF liczbę 10 (czyli $OA) i w efekcie uzyskujemy wartość 265, czyli w heksach $0109 (co komputer widzi jako 09 01). Zwróćcie uwagę, że ta liczba zapisana jest już w DWÓCH bajtach! W miejsce wpisanego FF wstawione zostaje więc 09, przez co nasza mana spada katastrofalnie. Go więcej, komputer wpisuje także liczbę 01 w ! rejestr, w którym zapisana jest np. inteligencja postaci. I proszę, mamy teraz za swoje: zamiast potężnego maga o przyzwoitej inteligencji, prowadzimy totalnego kretyna, o bardzo mizernej ilości many.. Czy na pewno o to chodziło człowiekowi, który modyfikował stan gry? Ha -kto heksami wojuje, od heksów ginie!
Wnioski: myślcie, ludziska, zanim coś pomieszacie w save, przewidujcie konsekwencje swoich działań i - J ^ mówi powiedzonko - gdy wyjadasz komuś zupę talerza, to rób to łyżeczką, a nie chochlą!
* * *
Czas na małą powtórkę - przypomnę wam systemie heksadecymalnym. Po co jeszcze raz o tym samym? Zaraz się przekonacie. Uwierz mi, że tak trzeba. A przy okazji możecie sprawdzić co zapamiętaliście z wcześniejszych części poradnika.
System heksadecymalny to system, w którym liczy komputer. To znaczy, nie jest to do końca prawdziwe twierdzenie. Otóż, każdy komputer liczy w rzeczywistości w systemie binarnym (dwójkowym). Oznaczało, iż komputer zna tak naprawdę tylko dwie cyfry: 1 i 0. Za ich pomocą jest w stanie zapisać każdą liczbę, l tak np. liczbę 13 komputer "widzi" jako 1101. Z punktu widzenia komputera jest to wygodne - z punktu widzenia człowieka, dla którego oczywistym jest system 10-tny (czyli zapis dowolnej liczby za pomocą 10 różnych cyfr [od O do 9]) - wprost przeciwnie. Ponieważ nauczenie komputera systemu 10-tnego jest (wbrew pozorom i powodom, które pominiemy) szalenie trudne i nieefektywne, konstruktorzy poszli na pewien kompromis. Otóż komunikacja pomiędzy nami i PCtami (na poziomie "mieszania" w grach) odbywa się za pomocą systemu szesnastkowego, zwanego uczenie haksadecymalnym (albo w skrócie hexami lub heksami).
Czym różni się system 16-tkowy od dziesiętnego? Otóż tym, że o ile w systemie 10-tym używamy 10 cyfr do zapisu dowolnej liczby, to w 16 -16. To logiczne, prawda? Ponieważ jednak nie znamy więcej niż 10 cyfr, to chcąc nie chcąc, "pożyczamy" sobie z alfabetu kilka liter, które odtąd będą dla nas cyframi. A są to liter od A do F. W ramce widać jak wygląda zapis tych samych liczb w systemie 16-tko-wym i 10-tnym. Ponieważ zapis liczb od O do 9 jest w obu systemach identyczny, zaczęliśmy od liczby 10.
Cała ta gadanina o heksach jest tylko wstępem do lekcji głównej - jak PCet zapisuje liczby. Wiecie, że w heksach. Ale nie wiecie wszystkiego. Nie wierzycie? Zatem proste pytanko: jaka jest największa liczba, którą roczna zapisać za pomocą dwóch cyfr układu szesnastkowego? (Dla układu 10-tnego jest to 99). Ponieważ największą cyfrą w heksach jest F, to wartość ta to: $FF - co oznacza 255 w układzie 10-tnym. Z tego prosty wniosek - maksymalna wartość, jaką można zapisać w jednym bajcie (któremu odpowiada jedna komórka widziana w save-game'ie, ta zaś zawiera dwa heksy) wynosi 25S. Co jednak, gdy poszukujemy w save gamę wartości większej niż 255? Powiedzmy, że szukamy stanu kasy, który wynosi 1000. Co wtedy, gdzie jej szukać, skoro w jedną komórkę wchodzi nie więcej niż 255?
l znów logika podpowiada, że jeśli coś nie mieści się w jednej "szufladzie", tym samym musi mieścić się - podzielone - w kilku sąsiednich "szufladach", czyli komórkach, l tak właśnie jest. Zobaczcie: zamieńmy 1000 na heksy. Otrzyma-mywartość$3E8. Pamiętacie zapewne, że każda badana przez nas liczba heksadecymalna NIE MOŻE mieć nieparzystej ilości elementów - a jeśli ma, to dodajemy zero na początku, by uzyskać parzystą ilość cyfr. Zatem dodajmy zero - i mamy już $03E8 (mam wnadzieję, że wiecie - tj. pamiętacie - czemu na początku liczby znajduje się symbol $?!). Pamiętacie też, że aby odnaleźć w save wartość kasy, musimy ponadto przestawić w przeliczonej na heksy cyfrze ($03E8) - tj. najpierw dzielimy ją na bajty: 03 E8, a potem zmieniamy ich kolejność na E8 03. l takiej to wartości poszukujemy w save'ie(*). Tj. jeśli znajdziemy wartość E8 03, to odpowiada ona za stan kasy o wysokości 1000.
Czemu tak się dzieje? Otóż PC zapisuje cyfry większe od 255 w kolejnych zespołach składających się z 2 kolejnych bajtów, zwanych bajtami starszymi i młodszymi. W tym przypadku 03 jest bajtem starszym, zaś E8 - młodszym. A zgodnie z ulubionym powiedzeniem rodziców ("ustąp młodszemu"), młodszy bajt powinien być na czele - podczas gdy kalkulator podaje nam liczbę przeliczoną na heksy w kolejności starszy/młodszy bajt. Tymczasem PC żąda na odwrót: młodszy/starszy. Stąd konieczność takiego przestawiania. Przy czym podkreślam, że przestawiamy kolejność BAJTÓW, a nie cyfr!, czyli AB CD = CD AB, a nie np. DC BA czy BA DC! Pojęli? Jeśli nie, to czytajcie następny akapit, tam wam dopiero zrobię wodę z mózgów!
Teraz popatrzcie, jak należy rozumieć to, że bajt jest starszy. (Bo ktoś zapyta - co to za różnica: młodszy czy starszy.) Co oznacza dla PC wartość 03 traktowana jako bajt starszy? Otóż oznacza to: 3 x $FF (czyli maks. wartość jednego bajtu) + $E8. (Ci, którzy są dociekliwi i sprawdzą te rachunki, zdziwią się, że przecież 3 x 255 + 232 = 997 a nie 1000... No dobra, przyłapaliście mnie: tak naprawdę to komputer liczy w tym momencie 3 x 256, a nie 255. Żeby Wam nie zaciemniać wykładu, po prostu przemilczę, CZEMU to robi, bo to akurat dla nas nieistotne.) Starszy bajt to jak banknot o wysokim nominale w portfelu, młodszy bajt to drobniaki. A warto umieć je odróżniać, nie?
Trochę praktyki: jeśli np. chcielibyście zamienić stan kasy z 1000 na 2000, to co robicie? Przeliczamy 2000 na heksy ($7DO), dodajemy O na początku, czyli 07 DO i robimy przestawiankę. Uzyskujemy DO 07 (czyli 208 + 7x256; kto nie wierzy - niech sprawdzi), l tą oto wartością zastępujemy pierwotny stan kasy. Proste!
Teraz sprowadzając to do grzebania w save'ach: jeśli zmieniacie stan kasy "na palę", to wpisanie większej wartości do bajtu starszego da nam od razu dużo większy przyrost kasy (patrzcie: E8 03 - gdy zamienimy 03 na 04, przybędzie nam od razu o 256 jednostek więcej, podczas gdy to samo 1 dopisane do E8 (czyli E9) da nam przyrost o... jedną jednostkę. Pojęli? A gdy zamiast 03 wpiszemy np. F3 - ho ho!).
Teraz nieco wyższa szkoła jazdy. Dwa bajty to również nie tak dużo, gdyż daje nam maksymalnie możliwość zapisania wartości $FFFF, czyli coś około 65.000. (Wyjmijcie karteczki... i dokładnie przeliczcie SFFFF na system 10-tny
.) A przecież są gry, gdzie np. obracamy setkami tysięcy dolarów czy milionami ton surowców itp. Więc co - jak PC zapisuje liczby powyżej tego 65.000 "z hakiem"? Otóż - tak samo. Nadal w zespołach bajtów młodszych/starszych! Tyle tylko że
wykorzystuje aż dwa kolejne takie zespoły (zwykle $FFFFFFFF kasy czy surowców NAPRAWDĘ wystarcza, by ukończyć każdą grę).
Powiedzmy, że szukamy wartości 11.259.375, która daje łatwy do zapamiętania heks $ABCDEF. Co z nim robimy? Otóż najpierw musimy podzielić go na DWA zespoły bajtów. A to oznacza, że musimy mieć liczbę składającą się z 8 cyfr (logiczne: 1 bajt = 2 cyfry, zatem 2 zespoły x 2 dwucyfrowe bajty = 8 cyfr). Co robimy? Otóż to samo co kiedyś - dodajemy ZERA na początku Ile? Tyle, by w wyniku uzyskać 8 cyfr. A ponieważ mamy tu 6 cyfr, nietrudno się domyślić, że dodajemy dwa zera.
Mamy już OOABCDEF. Rozdzielamy to na dwa zespoły bajtów - czyli na 2 elementy 4-cyfrowe. Co daje OOAB CDEF, a te z kolei na poszczególne bajty (mamy 00 AB i CD EF). Teraz sprawa jest prosta. Przestawiamy kolejność bajtów w każdym zespole. Zatem zamiast 00 AB, mamy AB 00, zamiast CD EF - EF CD. A co mamy w efekcie: AB 00 EF CD. Prawda, że to proste?
Finiszujemy: by odszukać wartość SABCDEF, szukamy w save ciągu bajtów AB 00 EF CD. l teraz pytanko - który z nich modyfikujemy, gdy chcemy od ręki i w ciemno zwiększyć sobie stan kasy o możliwie dużą wartość? Podpowiadam: starszy bajt drugiego zespołu. Czyli -CD. Czemu - to chyba oczywiste?
Uwaga: przestrzegam, póki co, przed radosnym wpisywaniem samych FF FF itp. Lepiej dodać mniej, niż ze zdumieniem stwierdzić, że... mamy UJEMNĄ kasę. Tak, PC to potrafi.
Stąd sugeruję wpisywanie, powiedzmy, 40% maksymalnej wartości, jaki możemy zapisać w save. Jeśli więc kasa zapisywana jest w dwóch bajtach, to maksymalna bezpieczna wartość, o jaką radzę zwiększać kasę sięga 40-45% od $FFFF (gdzie $FFFF= 65535).
l co - to było takie trudne? Jasne, że nie. Przecież mówiłem, że to całe "hakerstwo" jest równie skomplikowane, jak dłubanie w nosie...
A co, jeśli nadal za skarby świata nie możecie znaleźć w save-game poszukiwanych wartości, mimo pilnego studiowania tego kursu? Nie pękajcie. Jest parę metod grzebania, niekiedy niektóre gry szyfrują wartości właśnie w obronie przed takimi "ulepszaczami" jak my albo po prostu zapisują je w udziwniony sposób itp. itd. Zatem nie załamujcie się, wcale nie oznacza to, że jesteście głąbami. Wkrótce do tego dojdziemy!
* * *
Przed chwilą mocno was wymęczyłem sporą dawką dość trudnych teoretycznych rozważań o heksach itp. Dlatego teraz proponuję zwolnić tempo. Odpuścimy sobie bajty, bity, offsety... no - PRAWIE odpuścimy. Pomówimy teraz bowiem o rzeczach, które mogą czyhać na dokonującego poprawek w grach. O niektórych wspomniałem wcześniej, pora więc e pokazać wam, co jeszcze może was spotkać nieprzyjemnego przy tej zabawie.
Szczególnie tyczy się to ludzi grzebiących w save'ach gier RPG. Z jednej strony są one bardzo wdzięcznym polem do "mieszania" w stanach gry (z uwagi na mnóstwo rozmaitych współczynników dla każdej postaci), ale uważajcie - to dość grząski teren! Jak wspomniałem, czyhają tam na początkujących pewne pułapki, które skutecznie mogą zniechęcić niejednego ' grzeba-cza'. Żeby było śmieszniej, to w większości są to pułapki pozorne, tzn. programista wcale ich nie planował, a taki zielony "haker" klnie jego perfidię i dochodzi do wniosku, że lepiej dać sobie spokój z tą zabawą. A wszystko dlatego, że heksy przysłoniły mu oczy i nie potrafi już logicznie rozumować. Panowie - to, że umiecie przeliczać cyferki na heksy i zamieniać miejscami bajty, nie oznacza, że możecie przestawić mózg na jałowe obroty! Wprost przeciwnie! Tu trzeba CAŁY czas myśleć i mieć oczy szeroko otwarte, inaczej nigdy daleko nie zajdziecie.
Oto typowy przykład pozornej pułapki. Np. mimo zmodyfikowania jakiejś wartości (powiedzmy ilości mana). komputer twardo obstaje przy wartości, jaka była pierwotnie (tzn. po uruchomieniu save'u gość jak miał, tak ma tę samą ilość many, a edycja pliku pokazuje, że wpisana przez nas wartość została zastąpiona przez tę, która była przed naszą ingerencją). Odrzućmy tu perfidię programisty, który te same wartości ukrył w kilku miejscach save (na dodatek je szyfrując, by nie można ich było wykryć w tak prosty - jak opisuję - sposó
i po modyfikacji komputer, porównując nasz stan z "fabrycznymi" ustawieniami, odrzuca go jako przekłamanie i "naprawia" je.
Sprawa może być (i zwykle jest) dużo prostsza - np. ilość many może być powiązana z innym parametrem (np. mana = ilość punktów doświadczenia/100, lub mana = poziom doświadczenia * 10 - coś podobnego jest np. w HM&M 2). Po uruchomieniu gry komputer sprawdza wartość kluczowego parametru i odświeża zawartość podrzędnych (tj. związanych z nim) rejestrów. Dzięki temu wszelkie poprawki są bezcelowe, bo i tak zostaną zastąpione prawidłowymi wartościami. Naturalnie tylko do momentu, gdy... zmienimy wartość tego właśnie kluczowego parametru. Dlatego zachęcam do eksperymentów i nie radzę przejmować się kolejnymi klęskami; bo, jak śpiewał Jerzy Stuhr (wiele lat temu), "nie ma takiej rury, której nie można odetkać".
Inną pułapką są "klapki na oczach". Włamywacz widzi tylko to, co chce osiągnąć i wpisuje jakąś wartość, nie zwracając uwagi na powiązania wartości danego parametru z innymi czynnikami w grze. Tu, typowym przykładem jest stara, ale jara kosmiczna handlówka, czyli Fragile Allegiance. Początkujący ‘'haker” w łatwy sposób może niemal dowolnie zwiększyć ilość wydobytych minerałów w magazynach kolonii. Tyle tylko, że gra się wkrótce zawiesza.... "Poprawiacz" zapomniał bowiem zmodyfikować przy okazji pojemność... magazynów i przy pierwszej próbie przeniesienia 65 000 ton rudy z magazynu (o pojemności kilkuset ton....) do fabryk czy transportowca, gra mówł ‘’bye bye", ponieważ nijak nie może pogodzić faktu zgromadzenia kilkuset tysięcy ton minerałów w 600-tonowym pomieszczeniu...
Wniosek: poprawiać kompleksowo! l MYŚLEĆ!!!
Czasem jednak natraficie na rzeczywiste zabezpieczenia save'ów gry przed ingerencjami rozmaitych *mieszaczy'. Większość bardziej wyrafinowanych zabezpieczeń jest raczej nie do ominięcia przez ludzi, którzy nie są programistami. Ale na szczęście najczęściej autorzy gier, jeśli już zabezpieczają save, stosują bardzo proste metody. Widać wychodząc z założenia, że ekspert rozwali nawet najbardziej skomplikowane zabezpieczenia, a amatorzy i tak wyłożą się na najprostszym triku, więc po co się wysilać na jakieś wyrafinowane metody?
Bardzo popularnym sposobem jest stosowanie tzw. sumy kontrolnej. Save wygląda na niczym niezabezpieczony, wszystkie wartości jak na dłoni, ale wystarczy najdrobniejsza modyfikacja jakiejkolwiek wartości w jego obrębie, by komputer przestał go akceptować,informując - przy próbie wczytania - np. o uszkodzeniu pliku, przekłamaniu itp. Jak komputer rozpoznaje, że coś tam kombinowaliśmy? Ano - sprawdza sumę kontrolną. A CO TO JEST, U DIABLA!!! - zaryczał zapewne niejeden wkurzony już z lekka czytelnik. Otóż, mówiąc łopatologicznie: suma kontrolna jest to suma WSZYSTKICH wartości heksadecymalnych występujących w save'ie. Komputer zlicza tę wartość, sumując kolejne wartości w komórkach, w momencie gdy zgrywamy grę i zapisuje tę wartość gdzieś w save. A przed wczytaniem pliku komputer znów zlicza aktualną sumę wartości bajtów i porównuje ją z wcześniej zapisaną. Sumy się zgadzają - save jest wczytany. Nie zgadzają się - klops. Często zresztą ten zabieg nie jest skierowany przeciwko "hakerom", a rzeczywiście ma służyć wykluczeniu ewentualnych przekłamań w samym pliku save.
Mniejsza zresztą o przyczyny, dla których programista zastosował ten trick - ważne, jak to ominąć. Wbrew pozorom sprawa nie jest aż tak skomplikowana. Tyle tylko, że musimy mieć program, który umożliwia zliczanie sumy kontrolnej danego pliku. Istnieje cale mnóstwo aplikacji sharewareowych, które to wykonują, a każdy, kto ma choćby jakie takie pojęcie o programowaniu (choćby w Basicu) bez większych problemów stworzy sobie taką procedurkę. Teraz więc robimy tak:
1. Zliczamy sumę kontrolną save.
2. Odnajdujemy w nim taką wartość.
3. Edytujemy go.
4. Zliczamy nową sumę kontrolną.
5. Wpisujemy wartość nowej sumy w miejsce starej.
6. Uruchamiamy grę i puchniemy z dumy, jacy to mądrzy jesteśmy. ;-))))
A jeśli nie mamy żadnego takiego programu... Możemy wtedy zaryzykować inne zagranie: suma kontrolna znajduje się zwykle na samym końcu save'a (ale nie jest to reguła). Trzeba ją zidentyfikować "na nosa". A potem co? Np. poprawiliśmy stan kasy z 01 2F na FF AF. Więc w kalkulatorze odejmujemy od $ AFFF wartość $ 2F01 . Następnie uzyskany wynik dodajemy do wartości sumy kontrolnej i tę liczbę wpisujemy zamiast starej wartości. Nie gwarantuję, że to skuteczna metoda (jej słabością jest konieczność zlokalizowania "na oko" sumy kontrolnej), ale tonący brzytwy się chwyta...
Hym, widzę, że zostało nam jeszcze trochę miejsca... OK, porozmawiajmy o adresach. Czyich? Komórek (tj. kolejnych bajtów) w save. Adresy są jak ich PESELE numery telefoniczne - umożliwiają ich identyfikację. Jeśli edytowaliście save pod jakimkolwiek edytorem do przeznaczonym, widzieliście już zapewne coś takiego:
Adresy:
00000000 1A 00 00 00 34 56 78 90 00 A2 12 34 9A F4 77 AD
00000010 7B 40 03 00 C4 26 38 00 00 42 42 04 1A E4 E7 0E
00000020 00 01 10 45 73 62 84 00 30 32 32 54 OA 42 67 d3
Co oznaczają te zera (8) na początku? Oczywiście jest to adres pierwszej komórki w pierwszej linii - czyli tej, gdzie widzimy 1 A. OK. Zatem jaki adres będzie miała następna komórka? Otóż 00000001. A ponieważ pisanie takiej ilości zer jest męczące - możemy śmiało je wszystkie skreślić i powiedzieć, że jest ona umiejscowiona pod adresem (zwanym też offsetem) 01. Następna komórka to oczywiście 02 itd. Przy czym pamiętamy, że tutaj nadal obowiązuje system heksadecymalny, czyi: ostatnia komórka w rzędzie ma adres OF, przedostatnia - OE itd.
A co z adresami komórek drugiej linii? To samo, dokładnie to samo, tyle tylko, że zaczynamy rachunek od 10. Stąd pierwsza komórka drugiej linii ma adres 10, druga -11, ostatnia -1 F. Czujecie, o co chodzi?
A teraz popatrzcie, po co się tego uczycie. Jeśli ktoś powie, że np. kasa mieści się pod adresem 141 E, to co robimy? Możemy naturalnie użyć opcji GOTO (o ile nasz edytor ją ma) i skoczyć prosto pod ten adres. A możemy też odnaleźć linię 00001410 i znaleźć - którą komórkę w rzędzie? Skoro mamy tam E na końcu, to oczywiste jest, że... 15. Ktoś się żachnie, że $OE = 14, więc czemu szukamy PIĘTNASTEJ komórki w linii? Otóż zapomnieliście, że $OE równa się wprawdzie 14, ale przecież na początku mamy zero, tj. pierwsza komórka ma zerowy adres. Stąd komórki w linii liczymy nie jako 1 -2-3... itd., a 0-1-2-3). Prawda, że to oczywiste (gdy już to wiemy
).
A teraz to już naprawdę koniec...
PS Tradycyjnie już wyjaśniam, że temat 'sumy kontrolnej' nie został
wyczerpany ani nawet szczegółowo omówiony. Ale jak już kilka razy
pisałem - to nie lekcja informatyki, ja nie jestem od teorii, a od praktyki,
stąd pozwalam sobie na karygodne uproszczenia, łopatologię, przekłamania dla dobra sprawy
itd. Mam Was nauczyć grzebania w grach, stąd podaję tylko takie informacje i tylko w takim stopniu, by możliwie przystępnie wyjaśnić omawiany aktualnie temat. Zatem wszystkich fachowców, informatyków itp. proszę o wyrozumiałość, a dociekliwi mogą się dalej dokształcać we własnym zakresie. .
Życzę powodzenia!
Kilka przykładów:
1.Baldur's Gate
Edytuj plik baldur.gam w katalogu
save.
STR - 044C i 044D zmień to na (kolejno) 12,63
DEX-044Ezmieńtona12
CON-044Fzmieńtona12
INT- 0450 zmień to na 12 WIŚ - 0451 zmień to na 12
CHA - 0452 zmień to na 12
Ps. nie radzimy zmieniać tam wartości na więcej niż $12!
Kasa: 0018, 001 9 zmień na to FF, FF
EKPERIENCE: nie można przekraczać - modyfikując parametry - war-
tości $015BA8! Odszukaj adres
022C - wpisuj w kolejne komórki
wartości A8 5B 01 .
2. Fallout 2
Modyfikuj PLAYER.GCD.
Adres Komórki Skill
00000110 c-f Smali Guns
00000120 0-3 Big Guns
00000120 4-7 Energy Weapons
00000120 8-b Unarmed
00000120 c-f Melee Damage
00000130 0-3 Throwing
00000130 4-7 First Aid
00000130 8-b Doctor
00000130 c-f Sneak
00000140 0-3 Lockpick
00000140 4-7 Steal
00000140 8-b Traps
00000140 c-f Science
00000150 0-3 Repair
00000150 4-7 Speech
00000150 8-b Barter
00000150 c-f Gambling
00000160 0-3 Outdoorsman
Zmieniając zera na np. ciąg jedynek, otrzymujemy wartość 300%. Jest to po-
ziom maksymalny i jednocześnie minimalny (nie można go ani obniżyć, ani podnieść).
3.Kroniki Czarnego Księżyca
W katalogu gry wybrać katalog Sau-yegarde. Podkatalogi w nim to sa-vey. Należy wejść do wybranego katalogu i edytować plik sebinfo.txt. 11 linia zawiera ilość gotówki. Pliki regiment*.txt zawierają skład regimentów, na razie nie rozgryzłem do końca sposobu zapisu. Do tej pory wiem, że linia:
Regiment_nom =
(nazwa regimentu)
Regiment_pointsAction #
(punkty ruch na turę)
Regiment_nbSections #
(ilość zajętych sekcji w regimencie maks. 8)
Section_nom =
(nazwa sekcji np. Jeździec)
Section_numeroObjetMaitre #
(Prawdopodobnie typ jednostki)
Section_nbUnites #
(liczba jednostek w sekcji)
4.M&M VIII
Znajdź w save'ie imię Twego bohatera. 43 bity dalej znajdziesz trzy kolejne wartości.
Pierwsza odpowiada za rasę bohatera. Oto wartości, które możesz wpisać: 00 = Necromancer
01 = Lich
02 = Cleric
03 = Priest
04 = Knight
05 = Champion
06 = Troll
07 = War Troll
08 = Minotaur
09 = Minotaur Lord
OA = Dark Elf OB = Patriarch OC = Vampire OD = Nosferatu OE = Dragon OF = Great Wyrm
Możesz też trochę poszaleć, wpisując tamże:
10 = The Cursed
11 =TheWeak
12 = The Asleep
13 = TheAfraid
14 = The Drunk
15 = The Insane
16 = The Poison
17 = TheDiseased
18 = The Poison
19 = The Diseased
20 = The Eradicated
Drugi kolejny bajt odpowiada za portret bohatera.
Wpisz:
00 do 03 = Knight
(2 faceci & 2 kobiety) 04 do 07 = Cleric
(2 faceci & 2 kobiety) 08 do OB = Necromancer
(2 faceci & 2 kobiety) OC do OF = Vampire
(2 faceci & 2 kobiety) 10 do 13 = Dark Elf
(2 faceci & 2 kobiety) 14 i 15 = Minotaur
(1 facet & 1 kobieta) 16 i 17 = Troll
(1 facet & 1 kobieta) 18 i 19 = Dragon
(1 facet & 1 kobieta)
Byłoby fajnie, gdybyście dopasowywali jednak portrety do ras
Chciałbym zamieścić wam pewien poradnik, znalazłem go niedawno w Wielkiej Księdze Tipsów CDA - Lato 2002.
Napisał go Draco. Może komuś się przyda!!
Jeśli macie jakieś zastrzeżenie, znaleźliście błędy czy co piszcie!!
Jak (wy)grać gdy, nie ma tipsów i trainerów?
Jak skutecznie oszukać grę?
Jak włamać się do gry i zmusić ją do posłuchu?
Linki do programu:
http://www.piorunek.pl/prog/pliki/pliki/dn151.zip
Wstęp do wstępu
Wbrew pozorom niniejszy poradnik nie ma NIC wspólnego z prawdziwym hakingiem, aczkolwiek jeśli jesteś zainteresowany nauką grzebania w "bebechach" gry, celem ułatwienia sobie życia, to dobrze trafiłeś! Tu będzie mowa właśnie o tym! A jeśli zamierzasz tylko grać i masz wszystko inne w głębokim poważaniu i w życiu nie uruchomiłeś nawet żadnego programu użytkowego - mimo wszystko przeczytaj ten akapit, a nie pożałujesz. Przewrócić stronę zawsze zdążysz, te kilka(dzjesiąt) sekund cię nie zbawi. Ale jeśli uważasz, że interesuje cię tylko i wyłącznie granie i nie masz ambicji by to sobie ułatwić i robić coś więcej niż "pykanie" w rozmaitego typu gierek... to powiedzmy sobie tutaj "do widzenia". Ale nie narzekaj później, że nie możesz ukończyć tej czy innej gry. Gdybyś doczytał do końca, nie miałbyś takich problemów. Decyzja należy do Ciebie.
Draco
Wstęp właściwy
Graczy można podzielić na dwie kategorie. Ci pierwsi grają długo i uczciwie, z mozołem pokonując kolejne / gry. Druga kategoria to ludzie, którzy i owszem grają... ale tylko w gry w ten czy inny sposób "ulepszone” tak przez siebie, jak i innych spryciarzy (trainery, tisy itp.). Ci pierwsi na widok tych drugich pukają się w czoło, mówią coś o uczciwości, przyjemności płynącej z długotrwałej gry, radości z przejścia kolejnego etapu, 3 czym dodają z wyższością "wy tego nigdy nie zrozumiecie". Tamci rewanżują się z kolei przycinkami do ości zmarnowanego nad grą czasu, podczas mozol-i przechodzenia po raz 356 przez ten sam etap, wodzenia graczy za nos przez programistów itp.
Cóż - obie strony mają rację. Granie ma wszak dawać przyjemność i relaksować. Tyle tylko, że największą przyjemnością i relaksem dla pierwszej grupy jest uczciwe ukończenie gry, zaś dla "włamywaczy" nie ma większej radości niż namieszanie w jej parametrach i zmuszenie do działania wedle ich zasad. Mniejsza teraz o to czy jest to fair, czy nie fair. Zakładam, że sam nieraz, drogi graczu, zgrzytałeś zębami nad tą czy inną grą, w j beznadziejnie utknąłeś w miejscu nie do przejścia. A tu ani tipsów, ani trainerów... Dlatego - jeśli tylko chcesz - spróbuję wprowadzić cię do "przedszkola włamywacza". Po przeczytaniu tego poradnika powinieneś umieć skutecznie włamać się przynajmniej do części.
A czy będziesz chciał wykorzystać te umiejętności w praktyce - to już twoja sprawa. Osoby, które posiadają i choćby minimalną wiedzę na ten temat (o programistach nawet nie wspominając), ostrzegam, że wykład adresowany jest do zupełnie "zielonych" graczy, i będzie on bardzo "łopatologiczny" i będą w nim Omawiane rzeczy bardzo oczywiste, w sposób niekiedy potwornie uproszczony. Ale to nie jest lekcja informatyki...
Let's go!
Aby zostać włamywaczem, potrzebujesz niewiele: odrobiny chęci i dobrej woli, znajomości matematyki w zakresie tabliczki mnożenia, programu typu menadżer plików - np. DOS Nawigator [*] (jest na Cover CD w katalogu Tipsomaniak w Bonusie) lub jakiś inny manager plików zbliżony do DN charakterem, kartki papieru, czegoś do pisania... no i gry do eksperymentów. Zajmiemy się dziś najprostszym "włamywactwem", to jest modyfikacją zgrywek (save-game'ów). Sprawa jest - wbrew pozorom - prosta jak drut. Wystarczy tylko znać podstawowe zasady... Zabiegi są tak naprawdę równie trudne jak stuknięcie młotkiem w rurę, a cala sztuka (wcale nie tak skomplikowana) polega na tym, by wiedzieć GDZIE i JAK MOCNO stuknąć, l tego postaram się was nauczyć... Aby było łatwiej, poćwiczymy na jakiejś grze, np. Heroes Might & Magie 2. Póki co uruchomcie jednak nie grę - a wspomnianego DOS Navigatora... Gotowi? No to zaczynamy!
Ale zanim zaczniemy babrać się w komputerowych bebechach gry, musicie wysłuchać małego wykładu. W naszej zabawie będziemy bowiem stykać się ze sposobem zapisu wartości liczb, zwanym "systemem szesnastkowym" (heksadecymalnym). Różni się on od używanego przez nas systemu dziesiętnego tym, że wykorzystuje zamiast dziesięciu aż szesnaście cyfr do zapisu wartości liczby. Czemu tak? M.in. dlatego, że komputer woli heksy od systemu 10-tnego [**] i to musi starczyć za wszelkie argumenty, bo go nie przekonacie, by liczył "po ludzku". Mądrzejszy musi ustąpić...
No dobra. W systemie dziesiętnym po cyfrze "9" następuje liczba "10" (składająca się już z dwóch cyfr - 1 i 0), w systemie szesnastkowym zaś liczbę "1 0" zapisujemy jako "A" (a właściwie OA) . 1 1 to OB, 1 2 = OC, 1 3 = OD, 1 4 = OE, 14 = OF, zaś 16=10, 17 = 11 itp. Na początku może to być bardzo mylące i męczące dla graczy, dla których 1 0 to 1 0, a nie jakieś tam głupie OA! Aby nie męczyć się nieustannym przeliczaniem liczb dziesiętnych na heksadecymalne, możemy używać kalkulatora w DOS Nawigatorze (naciśnij CTRL-F6). Wpisując dowolną liczbę dziesiętną, w okienku HEX widzimy jej wersję heksadecymalną. Np. wpiszmy 45.454. Powinniśmy uzyskać liczbę B18E. Z kolei wpisując dowolną liczbę w systemie szesnastkowym (UWAGA: MUSI być poprzedzona symbolem dolara $, by komputer wiedział, że chodzi nam o heksy... bo przecież wartość np. 1234 może być liczbą zapisaną tak w systemie dziesiętnym, jak i szesnastkowym; znak $ oznacza natomiast "hej, to są heksy!"), np. $ABCD, uzyskamy wersję dziesiętną (43.981). Radzę to poćwiczyć!
Krótki egzamin?
1. Ile to jest (w heksach) 25000?
2. Przeliczcie wartość $DDAA na system dziesiętny.
Czemu o tym piszę? Otóż wszystkie liczby, z jakimi zetkniemy się podczas edycji save-game'u, to liczby heksadecymalne. Natomiast grając w dowolną grę, mamy na ekranie wszystkie parametry postaci, pojazdów itp. podawane w systemie dziesiętnym. Dlatego musimy nauczyć się przeliczać znalezione tam wartości na heksy. Np. chcąc podrasować grubość pancerza swego czołgu (powiedzmy 100 mm), musimy w save szukać wartości 64 (czyli 100 zapisane w systemie heksadecy-malnym). Teraz zmieniamy na np. 255 (naturalnie po przeliczeniu na heksy) i zastępujemy pierwotną wartość, l już nikt nam nie podskoczy. Proste, prawda? Przynajmniej wteorii. Ale praktyka jest... jeszcze prostsza, uwierzcie mi - a wkrótce sami to przyznacie!
Teraz uruchomcie Heroes Might & Magie 2. Zacznijmy grać w kampanię. Rozpoczynamy pierwszą misję, l na początku zastanówmy się, co chcemy zmienić w naszej grze? Podstawową bolączką gracza jest zbyt mata ilość pieniędzy. Zatem spróbujmy powiększyć nasz majątek
Jak? Zapiszmy sobie na razie ilość gotówki, jaką dysponujemy: 12.000 szt. złota. Po czym dokonujemy zgrania stanu gry i na razie żegnamy się z programem. Interesuje nas tylko sam plik save. A znajdziecie go w katalogu, jaki założył na twardzielu instalator HMM2, w podkatalogu GAMES, pod nadaną mu nazwą i z rozszerzeniem GMC. Znaleźć plik save jest zresztą prosto, ponieważ zwykle albo znajduje się on w jakimś katalogu typu SAVE, albo nazywa się savegame1 (2,3,4 itp.), albo - co jeszcze bardziej ułatwia nam robotę - ma nazwę, jaką nadaliśmy naszemu save podczas zgrywania stanu gry (np. Bolekl).
Ponownie uruchamiamy DN. Odczytujemy ten plik za pomocą klawisza F3 (spod wspomnianego Dos Navigatora - gdy stosujesz inny program, sam musisz "obcykać" klawiszologię). Nie przejmujcie się tym, co ujrzycie na ekranie. Ot, jakaś tam "kasza". Teraz klawiszem F4 (konwersja ASCII/Hex) zamieniamy tę kaszę na symbole ASCII i wartości heksadecymalne. Jeśli zrobiliście wszystko poprawnie, na ekranie mace (kolejno od lewej): słupek z ośmiocyfrowymi liczbami (adresami)-00000010, 00000020 itp. Co to jest itp., dowiecie się w swoim czasie, w tymże poradniku. Pośrodku widzicie heksadecymalne wartości kolejnych bajtów (przedstawiane jako zespoły składające się z kombinacji dwóch cyfr, liter lub cyfr i liter, np. 50 OA BC 00 00 DF 1 E). Te z kolei oddzielone są linią od wyświetlanych wartości ASCII. Jak znaleźć tu potrzebny nam stan gotówki?
1. Przeliczamy najpierw 12.000 na heksy. Powinniśmy uzyskać wartość 2EEO.
2. Teraz należy odszukać tę wartość w tysiącach cyfr i liczb, składających się na nasz save. Jak to osiągnąć?
3. Wybieramy klawisz F7 (Search) i wpisujemy w oknie HEX wartość... jaką? Wydaje się to oczywiste - naturalnie: 2EEO. ALE... to byłoby za proste. Z pewnych przyczyn (które w tej chwili są nieistotne) wartość tę dzielimy najpierw na dwuelementowe zespoły, czyli bajty: 2E i EO. Teraz dopiero wpisujemy w okno HEX tę wartość, tyle że w ODWROTNEJ kolejności: E02E. Komputer powinien odszukać wszystkie wartości E02E w całym save'ie. Jeśli jest tylko jedna taka liczba, to wszystko jest proste. Tu właśnie zapisany jest stan gotówki!
Ale co będzie, jeśli uzyskamy dużo więcej adresów, w których znajdziemy taką wartość? Co wtedy? Która liczba jest tą, której szukamy? Jak ją rozpoznać? Cóż, wtedy trzeba poeksperymentować. Zapisujemy wszystkie adresy (tj. numery tych linii, w których występują takie wartości, by potem je łatwiej odnaleźć), w których występuje ciąg EO 2E, wracamy do gry, i spokojnie czekamy jeden dzień w kampanii - stan naszej kasy zwiększa się o 1000, czyli mamy już na koncie 13.000. Znów zgrywamy stan gry, przeliczamy 13000 na heksy (co da nam 32C8) i tym razem szukamy tej wartości, naturalnie również zapisanej w odwrotny sposób (czyli C832). Jeśli w jednym ze spisanych adresów, gdzie przedtem znajdowała się wartość EO 2E znajdziemy teraz C8 32 to mamy 100% pewności, że właśnie w tym miejscu komputer zapisuje stan gotówki! Teraz więc wystarczy zamienić tę wartość na jakąkolwiek inną, wyższą (np. wpisując FF f f). Jak to zrobić? Po prostu ustaw kursor na danej komórce i wpisz tam nową wartość!
4. Teraz zgrywamy plik (gdy wychodzimy z Dos Navigatora, komputer zapyta czy zapisać zmiany - naturalnie tak!), uruchamiamy grę, wczytujemy save... i widzimy, że stan gotówki zwiększył się radykalnie. Jeśli wpisaliśmy FF FF, mamy teraz na koncie 65.535 sztuk złota (bo FF FF w heksach to 65.535 w systemie dziesiętnym, prawda?). Sporo... ale jednak nie za dużo. Wracamy więc do edycji save-game'a. Odnajdujemy wcześniej wpisaną wartość FF FF i zmieniamy ją na FF FF FF (ostatnie FF wpisujemy w następną wolną po FF FF komórkę). To da nam... (przeliczcie sobie...) 16.777.215 złota. Powinno wystarczyć! ;-).
l nie musicie nawet zbytnio szukać. Cash jest w tej grze ZAWSZE w ciągu komórek zaczynających się od adresu 04AF. Użyjcie (w trybie edycji save gamę) klawisza F5 (GOTO), wpiszcie ten adres... i już jesteście w domu. Wystarczy teraz wstukać tam wymaganą ilość gotówki. Nie radzę jednak (z przyczyn, które omówię w innym odcinku) wpisywać tam więcej jak FF FF FF!
Ze sporą gotówka, możemy bez problemu zakupić na targu dowolną ilość dowolnych minerałów. Ale powiedzmy, że jesteśmy za leniwi i nie chce się nam handlować. Chcemy za to pobawić się w edycję surowców. Nic prostszego. Spisujemy po prostu wartości kolejnych minerałów z okna informacyjnego w grze (drewno = 30, rtęć = 10, kamienie = 30, siarka = 10, kryształy = 10, klejnoty = 10). Przeliczamy je na heksy (30=14, 10 = OA). Teraz wystarczy poszukać ciągu bajtów 14 OA 14 OA OA OA. l co? Hm. Nie ma czegoś takiego. Dlaczego? Pomyślmy... w jednej komórce możemy zapisać maks. wartość FF, co daje nam w systemie dziesiętnym liczbę 255. Trochę mało - tych minerałów na pewno jest w grze dużo więcej. Może więc do zapisu ich wartości komputer rezerwuje na wszelki wypadek DWIE KOLEJNE komórki? Na początku, ponieważ dysponujemy małą ilością minerałów, są one puste, tzn. wypełnione zerami. Zatem powinniśmy poszukać ciągu komórek 14 00 OA 0014 00 itp. Nadal nic? To może na każdy minerał rezerwowane są trzy kolejne komórki, tj. trzeba szukać wartości 14 00 00 OA 00 00 14? Otóż to! Mamy taki adres!!! Teraz wystarczy więc wpisać odpowiednie wartości (ale nie więcej niż FF FF dla każdego surowca) i po kłopocie! Znów was wyręczyłem w poszukiwaniach i oto adresy, w których mieszczą się wartości poszczególnych minerałów: 0497 = drewno, 049B = rtęć, 04AO = kamienie, 04A3 = siarka, 04A7 = kryształy, 04AB = klejnoty.
Tyle na początek. Spróbujcie ew. poćwiczyć na innych
grach! Tu jednak ostrzegam, że:
-> nie każdą grę da się oszukać w taki sposób;
-> nie wiecie jeszcze wielu rzeczy, więc nie martwcie
się, gdy na początku się wam nie uda
-> zatem nie pękajcie gdy coś idzie nie tak!
UWAGA: przed rozpoczęciem jakichkolwiek manipulacji na save-game wykonaj wcześniej jego kopię bezpieczeństwa!!! Ważne!
Teraz chciałbym zrobić małą dygresję i opowiedzieć wam o niebezpieczeństwach związanych z włamywaniem się do save'ów gier. Efektem mieszania w nich często jest zawieszanie się gier lub - co gorsza - jakieś dziwne "przekręty" podczas rozgrywki (np. niespodziewane i na pozór bezsensowne zmiany rozmaitych parametrów - nawet tych, których nie modyfikowaliśmy!), niekiedy pojawiające się dopiero po jakimś czasie od naszej ingerencji. Czemu się tak dzieje? Zawieszanie może być naturalnie skutkiem wpisania jakiejś wartości do nieodpowiedniej komórki (myślimy, że modyfikujemy stan kasy, a okazuje się, że 'skaszaniliśmy* właśnie jakiś Bardzo Ważny Element Gry). Ale załóżmy, że mamy 200% pewności, iż dobrze zidentyfikowaliśmy dany adres. Czemu więc gra się zawiesza? Omówmy to na fikcyjnym przykładzie: w jakiejś grze RPG podkręcamy np. ilość energii magicznej (mana) z powiedzmy $2A [czyli 42] na miłe oczom $FF [255]. Wszystko potem gra, jesteśmy napakowani maną jak Arnold sterydami, świat jest piękny... Po czym np. napotykamy bandę orków, smażymy ich w pierwszym starciu jakimś fireballem na skwarki, następuje koniec tury... O, fuck!! Albo gra się kaszani, albo okazuje się, że ilość naszej many spada niespodziewanie do np. 03, a przy okazji zmieniła się np. inteligencja postaci (i to na gorsze). Co się dzieje?! Ano - zawiniła tu "chciwość" gracza i brak orientacji w informatycznym abecadle.
Zanim wyjaśnię to dokładniej, na chwilkę skończmy z tymi bardzo teoretycznymi rozważaniami - dla relaksu pora na nieco konkretniejsze informacje. W poprzednim artykule pisałem, że po przeliczeniu wartości dziesiętnej na heksy, jeśli zawiera się więcej niż w dwu elementach, dzielimy ją na dwucyfrowe wartości, celem dalszej obróbki (np. 3ACD to 3A CD). Tu od razu ktoś może mieć wątpliwość: "no dobra, ale ja otrzymałem wartość składającą się tylko z 3 cyfr, np. 14A. l jak to podzielić?". Otóż zasada jest taka, że w naszych rozważaniach NIE MA czegoś takiego jak liczba składająca się z nieparzystej ilości elementów. Co więc zrobić z bezczelnie nieparzysto-cyfrową wartością 14A? (A właściwie $14A, ponieważ zapamiętajcie raz na zawsze, że pisząc jakiekolwiek wartości heksadecymalne, poprzedzamy je znakiem $, by odróżnić je od wartości zapisanych w systemie 10-tnym.) Jak poradzić sobie z liczbą $14A? Rada jest jedna: w przypadku liczb heksadecymalnych, składających się z nieparzystej ilości cyfr (i liter), dopisujemy zero na początku ciągu. Czyli nie mamy już $14A, a $014A. Nie mamy $ABCDE - istnieje dla nas tylko $OABCDE! Nie ma $01B - jest $001 B! Teraz podział liczb na dwuelementowe kawałki przestał być problemem, prawda?
Wracamy do teorii! (Musicie ją opanować, choćby w minimalnym stopniu). Jak nasz PC-et zapisuje liczby? Otóż, jak wiadomo, zapisuje je w bajtach. W systemie heksadecymalnym w jednym bajcie można maksymalnie wpisać wartość $FF (255). A co będzie, jeśli trzeba zapisać wyższą wartość? Wykorzystuje się do tego kolejne (sąsiednie) bajty i stąd, by zapisać wartość 43.981 (w heksie $ABCD) PC zajmuje dwie sąsiednie komórki, wpisując do nich kolejno CD i AB (a czemu tak od końca - o tym później, by nie zamącić wam w głowach). Otóż załóżmy teraz, że w omawianej, hipotetycznej grze RPG maksymalna ilość many, jaką przewidział scenarzysta dla najbardziej nawet zaawansowanych postaci, miała nie przewyższać 100 (czyli $64 w heksach).
Programista zatem zarezerwował tylko jedną komórkę na zapis wartości tego parametru. A teraz taki początkujący 'haker1 wstawia tam FF (albo i FF FF). Po wpisaniu FF FF gra się natychmiast zawiesza. Why? Bo sąsiednia komórka mogła być odpowiedzialna za np. ogólną kondycję danej postaci (gdzie przewidziano wartości O -zdrowy, 1 - ranny, 2 - martwy) i wpisanie FF, a wiec wartości nie przewidzianej przez autora kodu, powoduję "ogłupienie" komputera, który nie wie, jak to zinterpretować... a to oznacza najczęściej zawieszenie się gry. Dobra, to jest zrozumiałe. Ale czemu dzieją się takie cuda z wartościami many i inteligencji? No cóż, eto wsio very proste;-). Gracz zwyczajnie... "przekręcił licznik"! Po usmażeniu orków komputer dodał nam punktów doświadczenia, a to z kolei owocuje zwiększeniem liczby many o np. 10 pkt. Komputer dodaje więc do $FF liczbę 10 (czyli $OA) i w efekcie uzyskujemy wartość 265, czyli w heksach $0109 (co komputer widzi jako 09 01). Zwróćcie uwagę, że ta liczba zapisana jest już w DWÓCH bajtach! W miejsce wpisanego FF wstawione zostaje więc 09, przez co nasza mana spada katastrofalnie. Go więcej, komputer wpisuje także liczbę 01 w ! rejestr, w którym zapisana jest np. inteligencja postaci. I proszę, mamy teraz za swoje: zamiast potężnego maga o przyzwoitej inteligencji, prowadzimy totalnego kretyna, o bardzo mizernej ilości many.. Czy na pewno o to chodziło człowiekowi, który modyfikował stan gry? Ha -kto heksami wojuje, od heksów ginie!
Wnioski: myślcie, ludziska, zanim coś pomieszacie w save, przewidujcie konsekwencje swoich działań i - J ^ mówi powiedzonko - gdy wyjadasz komuś zupę talerza, to rób to łyżeczką, a nie chochlą!
* * *
Czas na małą powtórkę - przypomnę wam systemie heksadecymalnym. Po co jeszcze raz o tym samym? Zaraz się przekonacie. Uwierz mi, że tak trzeba. A przy okazji możecie sprawdzić co zapamiętaliście z wcześniejszych części poradnika.
System heksadecymalny to system, w którym liczy komputer. To znaczy, nie jest to do końca prawdziwe twierdzenie. Otóż, każdy komputer liczy w rzeczywistości w systemie binarnym (dwójkowym). Oznaczało, iż komputer zna tak naprawdę tylko dwie cyfry: 1 i 0. Za ich pomocą jest w stanie zapisać każdą liczbę, l tak np. liczbę 13 komputer "widzi" jako 1101. Z punktu widzenia komputera jest to wygodne - z punktu widzenia człowieka, dla którego oczywistym jest system 10-tny (czyli zapis dowolnej liczby za pomocą 10 różnych cyfr [od O do 9]) - wprost przeciwnie. Ponieważ nauczenie komputera systemu 10-tnego jest (wbrew pozorom i powodom, które pominiemy) szalenie trudne i nieefektywne, konstruktorzy poszli na pewien kompromis. Otóż komunikacja pomiędzy nami i PCtami (na poziomie "mieszania" w grach) odbywa się za pomocą systemu szesnastkowego, zwanego uczenie haksadecymalnym (albo w skrócie hexami lub heksami).
Czym różni się system 16-tkowy od dziesiętnego? Otóż tym, że o ile w systemie 10-tym używamy 10 cyfr do zapisu dowolnej liczby, to w 16 -16. To logiczne, prawda? Ponieważ jednak nie znamy więcej niż 10 cyfr, to chcąc nie chcąc, "pożyczamy" sobie z alfabetu kilka liter, które odtąd będą dla nas cyframi. A są to liter od A do F. W ramce widać jak wygląda zapis tych samych liczb w systemie 16-tko-wym i 10-tnym. Ponieważ zapis liczb od O do 9 jest w obu systemach identyczny, zaczęliśmy od liczby 10.
Cała ta gadanina o heksach jest tylko wstępem do lekcji głównej - jak PCet zapisuje liczby. Wiecie, że w heksach. Ale nie wiecie wszystkiego. Nie wierzycie? Zatem proste pytanko: jaka jest największa liczba, którą roczna zapisać za pomocą dwóch cyfr układu szesnastkowego? (Dla układu 10-tnego jest to 99). Ponieważ największą cyfrą w heksach jest F, to wartość ta to: $FF - co oznacza 255 w układzie 10-tnym. Z tego prosty wniosek - maksymalna wartość, jaką można zapisać w jednym bajcie (któremu odpowiada jedna komórka widziana w save-game'ie, ta zaś zawiera dwa heksy) wynosi 25S. Co jednak, gdy poszukujemy w save gamę wartości większej niż 255? Powiedzmy, że szukamy stanu kasy, który wynosi 1000. Co wtedy, gdzie jej szukać, skoro w jedną komórkę wchodzi nie więcej niż 255?
l znów logika podpowiada, że jeśli coś nie mieści się w jednej "szufladzie", tym samym musi mieścić się - podzielone - w kilku sąsiednich "szufladach", czyli komórkach, l tak właśnie jest. Zobaczcie: zamieńmy 1000 na heksy. Otrzyma-mywartość$3E8. Pamiętacie zapewne, że każda badana przez nas liczba heksadecymalna NIE MOŻE mieć nieparzystej ilości elementów - a jeśli ma, to dodajemy zero na początku, by uzyskać parzystą ilość cyfr. Zatem dodajmy zero - i mamy już $03E8 (mam wnadzieję, że wiecie - tj. pamiętacie - czemu na początku liczby znajduje się symbol $?!). Pamiętacie też, że aby odnaleźć w save wartość kasy, musimy ponadto przestawić w przeliczonej na heksy cyfrze ($03E8) - tj. najpierw dzielimy ją na bajty: 03 E8, a potem zmieniamy ich kolejność na E8 03. l takiej to wartości poszukujemy w save'ie(*). Tj. jeśli znajdziemy wartość E8 03, to odpowiada ona za stan kasy o wysokości 1000.
Czemu tak się dzieje? Otóż PC zapisuje cyfry większe od 255 w kolejnych zespołach składających się z 2 kolejnych bajtów, zwanych bajtami starszymi i młodszymi. W tym przypadku 03 jest bajtem starszym, zaś E8 - młodszym. A zgodnie z ulubionym powiedzeniem rodziców ("ustąp młodszemu"), młodszy bajt powinien być na czele - podczas gdy kalkulator podaje nam liczbę przeliczoną na heksy w kolejności starszy/młodszy bajt. Tymczasem PC żąda na odwrót: młodszy/starszy. Stąd konieczność takiego przestawiania. Przy czym podkreślam, że przestawiamy kolejność BAJTÓW, a nie cyfr!, czyli AB CD = CD AB, a nie np. DC BA czy BA DC! Pojęli? Jeśli nie, to czytajcie następny akapit, tam wam dopiero zrobię wodę z mózgów!
Teraz popatrzcie, jak należy rozumieć to, że bajt jest starszy. (Bo ktoś zapyta - co to za różnica: młodszy czy starszy.) Co oznacza dla PC wartość 03 traktowana jako bajt starszy? Otóż oznacza to: 3 x $FF (czyli maks. wartość jednego bajtu) + $E8. (Ci, którzy są dociekliwi i sprawdzą te rachunki, zdziwią się, że przecież 3 x 255 + 232 = 997 a nie 1000... No dobra, przyłapaliście mnie: tak naprawdę to komputer liczy w tym momencie 3 x 256, a nie 255. Żeby Wam nie zaciemniać wykładu, po prostu przemilczę, CZEMU to robi, bo to akurat dla nas nieistotne.) Starszy bajt to jak banknot o wysokim nominale w portfelu, młodszy bajt to drobniaki. A warto umieć je odróżniać, nie?
Trochę praktyki: jeśli np. chcielibyście zamienić stan kasy z 1000 na 2000, to co robicie? Przeliczamy 2000 na heksy ($7DO), dodajemy O na początku, czyli 07 DO i robimy przestawiankę. Uzyskujemy DO 07 (czyli 208 + 7x256; kto nie wierzy - niech sprawdzi), l tą oto wartością zastępujemy pierwotny stan kasy. Proste!
Teraz sprowadzając to do grzebania w save'ach: jeśli zmieniacie stan kasy "na palę", to wpisanie większej wartości do bajtu starszego da nam od razu dużo większy przyrost kasy (patrzcie: E8 03 - gdy zamienimy 03 na 04, przybędzie nam od razu o 256 jednostek więcej, podczas gdy to samo 1 dopisane do E8 (czyli E9) da nam przyrost o... jedną jednostkę. Pojęli? A gdy zamiast 03 wpiszemy np. F3 - ho ho!).
Teraz nieco wyższa szkoła jazdy. Dwa bajty to również nie tak dużo, gdyż daje nam maksymalnie możliwość zapisania wartości $FFFF, czyli coś około 65.000. (Wyjmijcie karteczki... i dokładnie przeliczcie SFFFF na system 10-tny
wykorzystuje aż dwa kolejne takie zespoły (zwykle $FFFFFFFF kasy czy surowców NAPRAWDĘ wystarcza, by ukończyć każdą grę).
Powiedzmy, że szukamy wartości 11.259.375, która daje łatwy do zapamiętania heks $ABCDEF. Co z nim robimy? Otóż najpierw musimy podzielić go na DWA zespoły bajtów. A to oznacza, że musimy mieć liczbę składającą się z 8 cyfr (logiczne: 1 bajt = 2 cyfry, zatem 2 zespoły x 2 dwucyfrowe bajty = 8 cyfr). Co robimy? Otóż to samo co kiedyś - dodajemy ZERA na początku Ile? Tyle, by w wyniku uzyskać 8 cyfr. A ponieważ mamy tu 6 cyfr, nietrudno się domyślić, że dodajemy dwa zera.
Mamy już OOABCDEF. Rozdzielamy to na dwa zespoły bajtów - czyli na 2 elementy 4-cyfrowe. Co daje OOAB CDEF, a te z kolei na poszczególne bajty (mamy 00 AB i CD EF). Teraz sprawa jest prosta. Przestawiamy kolejność bajtów w każdym zespole. Zatem zamiast 00 AB, mamy AB 00, zamiast CD EF - EF CD. A co mamy w efekcie: AB 00 EF CD. Prawda, że to proste?
Finiszujemy: by odszukać wartość SABCDEF, szukamy w save ciągu bajtów AB 00 EF CD. l teraz pytanko - który z nich modyfikujemy, gdy chcemy od ręki i w ciemno zwiększyć sobie stan kasy o możliwie dużą wartość? Podpowiadam: starszy bajt drugiego zespołu. Czyli -CD. Czemu - to chyba oczywiste?
Uwaga: przestrzegam, póki co, przed radosnym wpisywaniem samych FF FF itp. Lepiej dodać mniej, niż ze zdumieniem stwierdzić, że... mamy UJEMNĄ kasę. Tak, PC to potrafi.
l co - to było takie trudne? Jasne, że nie. Przecież mówiłem, że to całe "hakerstwo" jest równie skomplikowane, jak dłubanie w nosie...
A co, jeśli nadal za skarby świata nie możecie znaleźć w save-game poszukiwanych wartości, mimo pilnego studiowania tego kursu? Nie pękajcie. Jest parę metod grzebania, niekiedy niektóre gry szyfrują wartości właśnie w obronie przed takimi "ulepszaczami" jak my albo po prostu zapisują je w udziwniony sposób itp. itd. Zatem nie załamujcie się, wcale nie oznacza to, że jesteście głąbami. Wkrótce do tego dojdziemy!
* * *
Przed chwilą mocno was wymęczyłem sporą dawką dość trudnych teoretycznych rozważań o heksach itp. Dlatego teraz proponuję zwolnić tempo. Odpuścimy sobie bajty, bity, offsety... no - PRAWIE odpuścimy. Pomówimy teraz bowiem o rzeczach, które mogą czyhać na dokonującego poprawek w grach. O niektórych wspomniałem wcześniej, pora więc e pokazać wam, co jeszcze może was spotkać nieprzyjemnego przy tej zabawie.
Szczególnie tyczy się to ludzi grzebiących w save'ach gier RPG. Z jednej strony są one bardzo wdzięcznym polem do "mieszania" w stanach gry (z uwagi na mnóstwo rozmaitych współczynników dla każdej postaci), ale uważajcie - to dość grząski teren! Jak wspomniałem, czyhają tam na początkujących pewne pułapki, które skutecznie mogą zniechęcić niejednego ' grzeba-cza'. Żeby było śmieszniej, to w większości są to pułapki pozorne, tzn. programista wcale ich nie planował, a taki zielony "haker" klnie jego perfidię i dochodzi do wniosku, że lepiej dać sobie spokój z tą zabawą. A wszystko dlatego, że heksy przysłoniły mu oczy i nie potrafi już logicznie rozumować. Panowie - to, że umiecie przeliczać cyferki na heksy i zamieniać miejscami bajty, nie oznacza, że możecie przestawić mózg na jałowe obroty! Wprost przeciwnie! Tu trzeba CAŁY czas myśleć i mieć oczy szeroko otwarte, inaczej nigdy daleko nie zajdziecie.
Oto typowy przykład pozornej pułapki. Np. mimo zmodyfikowania jakiejś wartości (powiedzmy ilości mana). komputer twardo obstaje przy wartości, jaka była pierwotnie (tzn. po uruchomieniu save'u gość jak miał, tak ma tę samą ilość many, a edycja pliku pokazuje, że wpisana przez nas wartość została zastąpiona przez tę, która była przed naszą ingerencją). Odrzućmy tu perfidię programisty, który te same wartości ukrył w kilku miejscach save (na dodatek je szyfrując, by nie można ich było wykryć w tak prosty - jak opisuję - sposó
Sprawa może być (i zwykle jest) dużo prostsza - np. ilość many może być powiązana z innym parametrem (np. mana = ilość punktów doświadczenia/100, lub mana = poziom doświadczenia * 10 - coś podobnego jest np. w HM&M 2). Po uruchomieniu gry komputer sprawdza wartość kluczowego parametru i odświeża zawartość podrzędnych (tj. związanych z nim) rejestrów. Dzięki temu wszelkie poprawki są bezcelowe, bo i tak zostaną zastąpione prawidłowymi wartościami. Naturalnie tylko do momentu, gdy... zmienimy wartość tego właśnie kluczowego parametru. Dlatego zachęcam do eksperymentów i nie radzę przejmować się kolejnymi klęskami; bo, jak śpiewał Jerzy Stuhr (wiele lat temu), "nie ma takiej rury, której nie można odetkać".
Inną pułapką są "klapki na oczach". Włamywacz widzi tylko to, co chce osiągnąć i wpisuje jakąś wartość, nie zwracając uwagi na powiązania wartości danego parametru z innymi czynnikami w grze. Tu, typowym przykładem jest stara, ale jara kosmiczna handlówka, czyli Fragile Allegiance. Początkujący ‘'haker” w łatwy sposób może niemal dowolnie zwiększyć ilość wydobytych minerałów w magazynach kolonii. Tyle tylko, że gra się wkrótce zawiesza.... "Poprawiacz" zapomniał bowiem zmodyfikować przy okazji pojemność... magazynów i przy pierwszej próbie przeniesienia 65 000 ton rudy z magazynu (o pojemności kilkuset ton....) do fabryk czy transportowca, gra mówł ‘’bye bye", ponieważ nijak nie może pogodzić faktu zgromadzenia kilkuset tysięcy ton minerałów w 600-tonowym pomieszczeniu...
Wniosek: poprawiać kompleksowo! l MYŚLEĆ!!!
Czasem jednak natraficie na rzeczywiste zabezpieczenia save'ów gry przed ingerencjami rozmaitych *mieszaczy'. Większość bardziej wyrafinowanych zabezpieczeń jest raczej nie do ominięcia przez ludzi, którzy nie są programistami. Ale na szczęście najczęściej autorzy gier, jeśli już zabezpieczają save, stosują bardzo proste metody. Widać wychodząc z założenia, że ekspert rozwali nawet najbardziej skomplikowane zabezpieczenia, a amatorzy i tak wyłożą się na najprostszym triku, więc po co się wysilać na jakieś wyrafinowane metody?
Bardzo popularnym sposobem jest stosowanie tzw. sumy kontrolnej. Save wygląda na niczym niezabezpieczony, wszystkie wartości jak na dłoni, ale wystarczy najdrobniejsza modyfikacja jakiejkolwiek wartości w jego obrębie, by komputer przestał go akceptować,informując - przy próbie wczytania - np. o uszkodzeniu pliku, przekłamaniu itp. Jak komputer rozpoznaje, że coś tam kombinowaliśmy? Ano - sprawdza sumę kontrolną. A CO TO JEST, U DIABLA!!! - zaryczał zapewne niejeden wkurzony już z lekka czytelnik. Otóż, mówiąc łopatologicznie: suma kontrolna jest to suma WSZYSTKICH wartości heksadecymalnych występujących w save'ie. Komputer zlicza tę wartość, sumując kolejne wartości w komórkach, w momencie gdy zgrywamy grę i zapisuje tę wartość gdzieś w save. A przed wczytaniem pliku komputer znów zlicza aktualną sumę wartości bajtów i porównuje ją z wcześniej zapisaną. Sumy się zgadzają - save jest wczytany. Nie zgadzają się - klops. Często zresztą ten zabieg nie jest skierowany przeciwko "hakerom", a rzeczywiście ma służyć wykluczeniu ewentualnych przekłamań w samym pliku save.
Mniejsza zresztą o przyczyny, dla których programista zastosował ten trick - ważne, jak to ominąć. Wbrew pozorom sprawa nie jest aż tak skomplikowana. Tyle tylko, że musimy mieć program, który umożliwia zliczanie sumy kontrolnej danego pliku. Istnieje cale mnóstwo aplikacji sharewareowych, które to wykonują, a każdy, kto ma choćby jakie takie pojęcie o programowaniu (choćby w Basicu) bez większych problemów stworzy sobie taką procedurkę. Teraz więc robimy tak:
1. Zliczamy sumę kontrolną save.
2. Odnajdujemy w nim taką wartość.
3. Edytujemy go.
4. Zliczamy nową sumę kontrolną.
5. Wpisujemy wartość nowej sumy w miejsce starej.
6. Uruchamiamy grę i puchniemy z dumy, jacy to mądrzy jesteśmy. ;-))))
A jeśli nie mamy żadnego takiego programu... Możemy wtedy zaryzykować inne zagranie: suma kontrolna znajduje się zwykle na samym końcu save'a (ale nie jest to reguła). Trzeba ją zidentyfikować "na nosa". A potem co? Np. poprawiliśmy stan kasy z 01 2F na FF AF. Więc w kalkulatorze odejmujemy od $ AFFF wartość $ 2F01 . Następnie uzyskany wynik dodajemy do wartości sumy kontrolnej i tę liczbę wpisujemy zamiast starej wartości. Nie gwarantuję, że to skuteczna metoda (jej słabością jest konieczność zlokalizowania "na oko" sumy kontrolnej), ale tonący brzytwy się chwyta...
Hym, widzę, że zostało nam jeszcze trochę miejsca... OK, porozmawiajmy o adresach. Czyich? Komórek (tj. kolejnych bajtów) w save. Adresy są jak ich PESELE numery telefoniczne - umożliwiają ich identyfikację. Jeśli edytowaliście save pod jakimkolwiek edytorem do przeznaczonym, widzieliście już zapewne coś takiego:
Adresy:
00000000 1A 00 00 00 34 56 78 90 00 A2 12 34 9A F4 77 AD
00000010 7B 40 03 00 C4 26 38 00 00 42 42 04 1A E4 E7 0E
00000020 00 01 10 45 73 62 84 00 30 32 32 54 OA 42 67 d3
Co oznaczają te zera (8) na początku? Oczywiście jest to adres pierwszej komórki w pierwszej linii - czyli tej, gdzie widzimy 1 A. OK. Zatem jaki adres będzie miała następna komórka? Otóż 00000001. A ponieważ pisanie takiej ilości zer jest męczące - możemy śmiało je wszystkie skreślić i powiedzieć, że jest ona umiejscowiona pod adresem (zwanym też offsetem) 01. Następna komórka to oczywiście 02 itd. Przy czym pamiętamy, że tutaj nadal obowiązuje system heksadecymalny, czyi: ostatnia komórka w rzędzie ma adres OF, przedostatnia - OE itd.
A co z adresami komórek drugiej linii? To samo, dokładnie to samo, tyle tylko, że zaczynamy rachunek od 10. Stąd pierwsza komórka drugiej linii ma adres 10, druga -11, ostatnia -1 F. Czujecie, o co chodzi?
A teraz popatrzcie, po co się tego uczycie. Jeśli ktoś powie, że np. kasa mieści się pod adresem 141 E, to co robimy? Możemy naturalnie użyć opcji GOTO (o ile nasz edytor ją ma) i skoczyć prosto pod ten adres. A możemy też odnaleźć linię 00001410 i znaleźć - którą komórkę w rzędzie? Skoro mamy tam E na końcu, to oczywiste jest, że... 15. Ktoś się żachnie, że $OE = 14, więc czemu szukamy PIĘTNASTEJ komórki w linii? Otóż zapomnieliście, że $OE równa się wprawdzie 14, ale przecież na początku mamy zero, tj. pierwsza komórka ma zerowy adres. Stąd komórki w linii liczymy nie jako 1 -2-3... itd., a 0-1-2-3). Prawda, że to oczywiste (gdy już to wiemy
A teraz to już naprawdę koniec...
PS Tradycyjnie już wyjaśniam, że temat 'sumy kontrolnej' nie został
wyczerpany ani nawet szczegółowo omówiony. Ale jak już kilka razy
pisałem - to nie lekcja informatyki, ja nie jestem od teorii, a od praktyki,
stąd pozwalam sobie na karygodne uproszczenia, łopatologię, przekłamania dla dobra sprawy
Życzę powodzenia!
Kilka przykładów:
1.Baldur's Gate
Edytuj plik baldur.gam w katalogu
save.
STR - 044C i 044D zmień to na (kolejno) 12,63
DEX-044Ezmieńtona12
CON-044Fzmieńtona12
INT- 0450 zmień to na 12 WIŚ - 0451 zmień to na 12
CHA - 0452 zmień to na 12
Ps. nie radzimy zmieniać tam wartości na więcej niż $12!
Kasa: 0018, 001 9 zmień na to FF, FF
EKPERIENCE: nie można przekraczać - modyfikując parametry - war-
tości $015BA8! Odszukaj adres
022C - wpisuj w kolejne komórki
wartości A8 5B 01 .
2. Fallout 2
Modyfikuj PLAYER.GCD.
Adres Komórki Skill
00000110 c-f Smali Guns
00000120 0-3 Big Guns
00000120 4-7 Energy Weapons
00000120 8-b Unarmed
00000120 c-f Melee Damage
00000130 0-3 Throwing
00000130 4-7 First Aid
00000130 8-b Doctor
00000130 c-f Sneak
00000140 0-3 Lockpick
00000140 4-7 Steal
00000140 8-b Traps
00000140 c-f Science
00000150 0-3 Repair
00000150 4-7 Speech
00000150 8-b Barter
00000150 c-f Gambling
00000160 0-3 Outdoorsman
Zmieniając zera na np. ciąg jedynek, otrzymujemy wartość 300%. Jest to po-
ziom maksymalny i jednocześnie minimalny (nie można go ani obniżyć, ani podnieść).
3.Kroniki Czarnego Księżyca
W katalogu gry wybrać katalog Sau-yegarde. Podkatalogi w nim to sa-vey. Należy wejść do wybranego katalogu i edytować plik sebinfo.txt. 11 linia zawiera ilość gotówki. Pliki regiment*.txt zawierają skład regimentów, na razie nie rozgryzłem do końca sposobu zapisu. Do tej pory wiem, że linia:
Regiment_nom =
(nazwa regimentu)
Regiment_pointsAction #
(punkty ruch na turę)
Regiment_nbSections #
(ilość zajętych sekcji w regimencie maks. 8)
Section_nom =
(nazwa sekcji np. Jeździec)
Section_numeroObjetMaitre #
(Prawdopodobnie typ jednostki)
Section_nbUnites #
(liczba jednostek w sekcji)
4.M&M VIII
Znajdź w save'ie imię Twego bohatera. 43 bity dalej znajdziesz trzy kolejne wartości.
Pierwsza odpowiada za rasę bohatera. Oto wartości, które możesz wpisać: 00 = Necromancer
01 = Lich
02 = Cleric
03 = Priest
04 = Knight
05 = Champion
06 = Troll
07 = War Troll
08 = Minotaur
09 = Minotaur Lord
OA = Dark Elf OB = Patriarch OC = Vampire OD = Nosferatu OE = Dragon OF = Great Wyrm
Możesz też trochę poszaleć, wpisując tamże:
10 = The Cursed
11 =TheWeak
12 = The Asleep
13 = TheAfraid
14 = The Drunk
15 = The Insane
16 = The Poison
17 = TheDiseased
18 = The Poison
19 = The Diseased
20 = The Eradicated
Drugi kolejny bajt odpowiada za portret bohatera.
Wpisz:
00 do 03 = Knight
(2 faceci & 2 kobiety) 04 do 07 = Cleric
(2 faceci & 2 kobiety) 08 do OB = Necromancer
(2 faceci & 2 kobiety) OC do OF = Vampire
(2 faceci & 2 kobiety) 10 do 13 = Dark Elf
(2 faceci & 2 kobiety) 14 i 15 = Minotaur
(1 facet & 1 kobieta) 16 i 17 = Troll
(1 facet & 1 kobieta) 18 i 19 = Dragon
(1 facet & 1 kobieta)
Byłoby fajnie, gdybyście dopasowywali jednak portrety do ras
