Witam, ostatnio zainteresowala mnie pewna kwestia, mianowicie chodzi o zmiane dzialania programu napisanego przez kogos.
Np. ostatio wyszla nowa czesc Call Of Duty i byla afera ze gra sie nie uruchamia na kompach o ilosci RAM < 6 GB (mimo ze gra wykorzystywala ok. 2 GB). Wkrotce pojawil sie atch, ktory usuwal to ograniczenie. No i moje pytanie tutaj - jak to dziala? Przeciez na komputerze sa tylko skompilowane pliki gry wiec nie moza sobie go swobodnie zmodyfikowac..
Domyslam sie ze z aplikacjami open-source jest latwiej, bo mamy pod reka ich kod zrodlowy i mozemy go zmienic, skompilowac i podmieic skompilowany plik ze starym, ale jak sobie poradzic w przypadku takiej gry czy czego kolwiek innego gdzie mamy tylko kilka plikow .exe, .dll czy podobnych?
Jest coś takiego jak http://pl.wikipedia.org/wiki/Asembler i każdy kto go potrafi i ma czas oraz chceci, to może modyfikować wcześniej skompilowany program. Właśnie w taki sposób robi się cracki do gier/programów.
W przypadku aplikacji opensource to jest tylko kwestia znalezienia odpowiedniego miejsca w kodzie (w ASM też,ale jest to trudniejsze) i kompilacji.
Kiedyś była popularna wprawka dla adeptów tej sztuki. Dodawało się do MS Notatnika pozycję w menu wysyłającą treść otwartego pliku mailem :)
Haslo na dzis: reverse engineering
http://re.coldwind.pl
to podepnę się do tematu i zapytam, czy twórcy najnowszego call of duty celowo zrobili funkcję sprawdzającą ilość ramu i warunek typu
IF wielkość_ramu < 6 GB then nie_odpal_gry_i_wyswietl_info_o_zbyt_malym_ramie();?
Dlaczego tak postąpili? Producent ramu sypnął kasiorę by tak zrobili, czy jak? Bo nie rozumiem tego tym bardziej, że ta gra nawet do połowy tej wartości ramu nie dochodzi więc 4 GB limit mogliby dać i nigdy nie zostałoby wykorzystane np. 3900 MB ramu. Krótko mówiąc, nie widzę sensu w tej zagrywce twórców gry. Może wy mi znajdziecie ten sens :D (i to chyba jedyna gra na świecie z takim ograniczeniem nonsensownym)
- Wątpię żeby to był taki wrunek ;)
- Wyobraź sobie że w połowie gry trafiasz na mapę i misję gdzie faktycznie potrzeba 6GB i niestety nie możesz przejść dalej...
a z patchem na zdjęcie ograniczenia na 3, 4 GB ramu całą grę przejść pewnie można bez problemu
Akurat na ten temat jest cala dyskusja i artykul w necie wiec mozecie sobie wyguglowac. Od siebie mam jeszcze pytanie, otoz wiki o deasemblacji mowi tak: "W większości przypadków nie jest możliwa skuteczna metoda zamiany kodu maszynowego na język asemblera, analizator nie jest w stanie rozróżnić danych od kodu i interpretuje dane umieszczone w kodzie programu jak instrukcje". Problem wyolbrzymiany czy naprawde jest to syzyfowa praca?
Jeśli założymy, że program nie był potraktowany narzędziem utrudniającym disassemblację (co za wyraz), to raczej nie ma z tym problemu. Tak, architektura procesorów x86 nie rozróżnia kodu od danych. Kod można modyfikować jak dane, dane można wykonywać. Ale to są raczej rzadko spotykane sztuczki niż standardowe działanie klasycznych kompilatorów.
Chyba, że żyję w nieświadomości. Ostatnio bawiłem się tym dekadę temu...
W większości przypadków nie jest możliwa skuteczna metoda zamiany kodu maszynowego na język asemblera, analizator nie jest w stanie rozróżnić danych od kodu i interpretuje dane umieszczone w kodzie programu jak instrukcje". Problem wyolbrzymiany czy naprawde jest to syzyfowa praca?
Dlatego dezasemblery stosują różne sposoby na zgadnięcie, czy dane bajty są sekwencją instrukcji czy to tylko dane. Kod jest analizowany pod względem sensu: zaczynamy od punktu wejścia programu, który wiadomo że jest kodem. Wszystkie lokacje do których odwołują się instrukcje skoków są oznaczane jako na pewno kod – powstaje drzewo kodu i możliwa jest dalsza analiza.
Podobnie lokacje na których wykonywane są instrukcje do manipulowania danymi oznaczane są jako dane.
Rzeczywiście dezasembler łatwo oszukać modyfikując kod w pamięci, albo wykonując dane – ale w normalnym programie takie operacje się nie pojawiają.
Ale to są raczej rzadko spotykane sztuczki niż standardowe działanie klasycznych kompilatorów.
„Poważne” zastosowania dla wykonywania danych jakie mi przychodzą do głowy to packery exeków (np. UPX) - rozpakowują kod do pamięci po to by doń za chwilę skoczyć, oraz kompilatory JIT (np. .NET Framework) - kompilacja z bytekodu; w przeciwieństwie do Javy .NET nie ma trybu interpretera, wszystko musi być najpierw przemielone przez JIT do kodu natywnego.