Tytuł: Zaglądamy do RGSS Playera
Opracował: Pajper
Email:
dawidpieper@o2.pl
Słowo wstępne od autora
Uwaga! Ten poradnik jest napisany dla osób, które nie boją się odrobiny ryzyka i są bardziej zaawansowane w dziedzinie informatyki. Przed rozpoczęciem jakichkolwiek operacji, zaleca się stworzenie kopii zapasowej projektu, gdyż błąd może spowodować jego uszkodzenie.
Dzisiaj chcę Wam przedstawić sposoby na edycję samego silnika RGSS przy użyciu dostępnych metod binarnych. Po co taka zmiana? Przyczyn może być wiele. To, co dzisiaj pokażę, to podstawy - wiedzę tę można rozwijać dalej. Dowolna zmiana w makerowym game.exe może nam pozwolić na lepsze dostosowanie gry, zmianę komunikatów, wpisów, szyfrowanie danych, tłumaczenie różnych informacji itp.
Mam nadzieję, że poradnik się przyda.
~Pajper
Co będzie nam potrzebne?
Oj, tego jest dużo. :)
1. Jakiś edytor zasobów (zalecam program Resource Hacker).
2. Jakiś dezasembler (zalecam W32DASM Disassembler).
3. Jakiś edytor programistyczny ze wsparciem binarnym (notatnik na pewno nie pomoże - zalecam notepad++).
Jak działa RGSS Player?
Zanim zabierzemy się do czegokolwiek, zacznijmy od zastanowienia się, jak nasz RGSS Player działa.
1. Stworzenie przestrzeni na dane.
2. Odszukanie i dołączenie wymaganych bibliotek i komponentów.
3. Odszukanie pliku konfiguracji projektu (.ini).
4. Pobranie nazwy gry.
5. Utworzenie okna gry.
6. Pobranie ścieżki biblioteki RGSS.
7. Załadowanie biblioteki RGSS.
8. Załadowanie interpretera Ruby i RTP.
9. Załadowanie skryptów.
10. Uruchomienie skryptów i rozpoczęcie przetwarzania kodu Ruby.
Jak widać, nie jest to szczególnie skomplikowany algorytm, sam program game.exe ma jedynie 68KB.
Edycja zasobów
Każdy plik wykonywalny może zawierać tak zwane zasoby. Są to materiały takie jak ikona, kursor i jakieś inne dane. Przy pomocy edytora zasobów możemy otworzyć nasz plik. Widać tutaj ikonki, kursory i dane xml (więcej o tym w
zaawansowanym kursie RGSS). Dzięki prostym kreatorom z menu możemy łatwo zmienić kursor myszy czy ikonę programu. Po zmianie, wybieramy opcję compile - jeśli się pojawi, a następnie save z menu file. Zmiana zasobów jest stosunkowo bezpiecznym procesem, to tak powstają tłumaczenia RM, który właśnie w zasobach ma swoje informacje o wyświetlanych komunikatach.
Dezasemblacja
No cóż, teraz coś bardziej zaawansowanego. Zalecany przeze mnie dezasembler jest dość stary, ale sprawdza się znakomicie. Z menu Disassembler wybierzmy opcję Open file to disassemble
. Wybierzmy plik game.exe i poczekajmy na zakończenie procesu dezasemblacji, u mnie to trwa jakąś sekundę. :) Teraz możemy podziwiać kod asemblera naszego projektu. Jak widać, jest dość skomplikowany. To dlatego, że ASM jest językiem procesora. Funkcje w nich wyglądają dokładnie tak, jak w procesorze. Ten kurs nie jest nauką asemblera, więc nie będę wszystkiego tłumaczył, zainteresowanych zapraszam do Internetu.
Poza setkami instrukcji dla procesora widać tu jednak również kilka przydatnych informacji, jak używane biblioteki, importowane funkcje itp. W menu Refs można znaleźć opcję String Data References. Po jej otwarciu zobaczymy wszystkie dłuższe dane z łańcuchami znaków. Dzięki temu można na przykład zmienić nazwę z tej, pod jaką widzi ją Windows - RGSS Player - na nazwę naszej gry. Trzeba tylko znaleźć odpowiednie linijki i wszystkie RGSS Playery zmienić w odpowiedni sposób. To tyle z ASM. Wiedza o tym, co było tutaj, przyda się już w edycji binarnej. Zapamiętanie nazw funkcji i bibliotek może nam wskazać już w samej binarce, co do czego służy.
Przegląd binarny
Jak powszechnie wiadomo, komputery widzą dane jako ciągi bitów 0..1. Osiem takich bitów tworzy bajt - 0..255. Bajty są niekiedy zapisywane jako dwie cyfry heksagonalne 00..ff. Każdy bajt odpowiada również jakiemuś znakowi w unikodzie - A = 65; C = 67; 0 = 48 itp. Szczegółową tabelkę również można znaleźć we wspominanym kursie RGSS. :) Nie jest to jednak jedyne zastosowanie bajtów. Każdy bajt bowiem coś również oznacza dla procesora, jakąś akcję. Rozpisanie tych bajtów w rozsądny sposób mogliśmy podziwiać w Asemblerze. Niezależnie od instrukcji sekcji, w podstawowych edytorach programistycznych zobaczymy je jako ciąg najdziwniejszych bajtów. Plik game.exe zawiera ich dokładnie 69 632. Co to dla nas znaczy? O tym za chwilę.
Uruchommy nasz edytor ze wsparciem do danych binarnych. Jako plik wskażmy nasz plik game.exe. To, co zobaczymy, z pewnością wygląda bardzo interesująco, ale niewiele mówi. Rzućmy więc na to trochę światła. Na początek: "MZ". Ten kod w pięknej formie binarnej wygląda tak: 100110101101010010000, a w formie heksagonalnej tak: 4D5A90. Oznacza to, że program jest aplikacją exe działającą w procesorze x86. Wszystkie pliki exe x86 będą miały taki początek. Potem następują różne instrukcje dla procesora, których zadaniem jest inicjacja programu. Przeważają tu puste bajty (00000000), które oznaczają, że program czegoś nie ma, np. jakiś zasobów graficznych. Jest tu też jednak kilka bajtów częściowo wypełnionych. Szczerze mówiąc, sam nie domyślam się znaczenia wszystkich.
Właśnie do tego powstał ASM, żeby zamiast bawić się w formy binarne, mieć to przed sobą rozpisane w normalny sposób. Co jednak można tutaj zmienić, jeśli to tak dziwnie wygląda? Cała pierwsza linijka zawiera jakieś dziwne bajty, ale kończy się słowami. "This program cannot be run in DOS mode." Oznacza to, że program informuje system, że nie może być uruchomiony pod DOS'em. Co to oznacza w praktyce? Wiemy, że w tym momencie najważniejsze komponenty są załadowane. Tak właśnie wygląda praca w danych binarnych. Często sprowadza się do domysłu - może ten bajt coś nam przypomni, a może jakiś napis nas na coś skieruje... Zadaniem tego poradnika nie jest jednak pozostawienie Was z domysłami, a pokazanie gotowych i rozpracowanych już informacji, przy czym pokażę, jak do nich dojść samemu. Więc tak...
Na początek zalecam zablokować edycję z menu edycja. Nie jest to wymagane, ale na czas szukania jakichś danych to zalecam, żeby przypadkiem nie dopisać jakiegoś bajta - dowolny znak lub podział linii. Jeden bajt różnicy może zniszczyć cały program. Jednak prócz instrukcji dla procesora, pliki te zawierają wartości stałych liczbowych, tekstowych i wstępne wartości zmiennych. Jeśli się ich doszukać, można coś zmienić. Niestety, liczby są również bajtami, na przykład znak 5 oznacza wartość 53, więc nie jest to zbyt logiczne. Trzeba też przeanalizować kod (najlepiej ASM), żeby zobaczyć, która zmienna do czego się odwołuje. Z napisami nie jest tak źle. Raczej nie spotykamy tekstu z jednej, dwóch czy trzech liter - jest ich więcej - całe wyrazy lub zdania. Zdania te będą wyraźnie widoczne w edytorze, gdyż nie są zapisane w formie cyfrowej, a literowej. Właśnie dlatego uparłem się, by przeglądać bajty w tej formie, a nie zerojedynkowej.
Jako że wciąż tych bajtów jest prawie 70000, proponuję użyć dobrodziejstwa zwanego wyszukiwaniem. Wpiszmy słowo Title. Znajdziemy linijkę o wszystko mówiącej i bardzo ładnej treści ;), która zawiera jednak pewne bardzo ciekawe dla nas rzeczy. Są to mianowicie łańcuchy znaków, które zapisano jako stałe. Można tu znaleźć kilka nazw znanych nam z kodu ASM. Są to wywoływane funkcje - sekcja Imported się kłania. Widać tu też takie stringi, jak "Game", "Title", "Scripts"... Są to importowane dane z .ini. W ten sposób możemy zmienić nazwy kluczy importowanych z ini.
Teraz najtrudniejsze. Zmieniając jakiekolwiek wartości, musimy pamiętać o tym, że rozmiar pliku to 69632 bajty. Jeśli nasza nowa forma jest krótsza niż ta podana, należy dopisać na przykład spacje lub wstawić znaki zerowe (edycja \ wstaw znak zerowy). Jeśli jest dłuższa, musimy skasować znaki zerowe po końcu terminu pierwotnego. Jeśli wchodzimy na jakieś znaki, które zerowymi nie są, nie możemy wpisać tak długiego terminu. Proponuję tu użyć synonimów. Przed każdą kolejną zmianą zalecam sprawdzać, czy plik ma 69632B. Jeśli nie, to dopisać / usunąć jakieś znaki w zależności od potrzeby. Dlaczego to zrobić przed każdą zmianą? Żeby pamiętać, gdzie dokonaliśmy modyfikacji. Nie można dopisać lub usunąć bajta gdziekolwiek. W pliku tym też są nazwy bibliotek, jak user32. Jeśli jesteśmy programistami C++ itp., możemy je zastąpić naszymi własnymi modułami. Co jednak najważniejsze: w stringach znajdują się dwie wartości: .ini i .rgssad. Możemy więc zmienić rozszerzenia plików.
I są tu komunikaty o błędach, które można przetłumaczyć. Po wszystkim, wystarczy zapisać plik. Właśnie dlatego nie można użyć Windowsowego notatnika - nie jest on w stanie zapisać kodu binarnego, uszkodziłby nam plik.
