Happy Freezer, Turbo Freezer, Code3 freezer oraz inne klony wykorzystują NMI, generują je podczas naciśnięcia przycisku. Wystarczy zablokować NMI ($d40e == 0) i przycisk Freezera nie zadziała. Do kompletu jest co najmniej kilkanaście sposobów wykrycia faktu użycia Freezera i przy powrocie do Freezowanego programu system się już nie pozbiera.
Mającym Freezera z tej serii proponuję np. odpalić Digital Studio lub Sample Editor i zobaczyć co się stanie po wyjściu z menu freezera ;)
Mając Freezera zamontowanego od K.Steca dużo czasu spędziliśmy (jako Code3 czy Slight) na zabawie w różne "wykładanie" go, przy okazji badając jego zasadę działania a co za tym idzie odkrywając różne słabości i podatności.
Z tego co pamiętam oryginał gry Technoid (wydanej przez Stanbit) również posiadał zabezpieczenie anty-freezer naszego autorstwa.
Jeżeli chodzi "fałszywy" REF który generował freezer było to robione po to aby uniknąć konfliktu z możliwością wystąpienia jednocześnie przerwania NMI pochodzącego od ANTIC-a i tego generowanego z przycisku.
Jednak blokada NMI nie rozwiązywała do końca problemu z zabezpieczeniem się przed freezerem, wystarczylo trzymać wciśnięty przycisk "Freeze" a potem nacisnąć RESET. Co prawda nie można było już powrócić do freezowanego programu ale zawartość pamięci nie ulegała zniszczeniu, co zanim OS pozamiatał to freezer przejmował kontrolę.
Przy hackowaniu jakiegoś programu oczywiścia sam zrzut pamięci dawał już bardzo dużo, można było po prostu przeanalizować kod/dane znajdujące się pamięci z chwili wykonania tej akcji. Niejednokrotnie to wystarczało aby dość szybko złamać dany program.
Piszę oczywiście wszystko z pamięci, to były dawne dzieje i część faktów mogłem przekręcić lub być mało precyzyjnym, wybaczcie mieliśmy wtedy po "naście" lat. Jak pisałem to niejednokrotnie gdyby nie Freezer cały devleopment Overmind, Bitter Reality czy część pamięciożernych efektów trudno byłoby zrealizować/uruchomić w sensownym czasie. To narzędzie bardzo przyspieszało "development".
Przykład? Pisaliśmy oczywiście w QA, aby było szybciej assemlowaliśmy dane procki czy efekt bezpośrednio do pamięci komputera (np. od adresu $700, więc niszczyliśmy DOS). Przed taką akcją jednak wykonywaliśmy freeze-a do pamięci ext. zamontowanej w komputerze. Po asemblacji i uruchomieniu programu, notowaliśmy błędny analizowaliśmy pamięć, etc.
Po czym można było dokonać poprawek po "odfreezowaniu" ostatniego ... hmmm... dziś to byśmy nazwali "snapshoota" :D
Jak dany efekt, procka, etc. zadziałał można było zgrać źródło na dyskietkę jako działający proc/efekt. W ten sposób unikaliśmy czasochłonnego asemblowania na dysk, includowania, budownia całej binarki od nowa.
Nie chcę nic obiecywać, bo nie wiem czy to jeszcze znajdę, ale na sam koniec działalności Krzyśka Steca na giełdzie dostałem od niego gołe PCB do freezera oraz jakieś ledwie czytelną kartę z notatkami... jeżeli to znajdę to oczywiście udostępnię. Powinienem był to zrobić oczywiście o wiele wcześniej, ale trochę rzeczy mi się w życiu pokomplikowało i wszystko idzie wolniej niż bym chciał.
Już o tym pisałem we wcześniejszych wątkach, ale powtórzę i tutaj... niestety analiza działania freezera od strony elektronicznej była nam bardzo utrudniona przez Krzyśka Steca, gdyż jego działo po założeniu wyglądało tak:
niestety próbując to odkuć w tamtych czasach tylko zniszczyłem sobie freezera i musiałem zapłacić za montaż ponownie ;/ Ciekawość wygrała wtedy z rozsądkiem :) Ale nie żałuję... bez tej walki z Krzyśkiem nigdy nie powstały by poprawki do Happy Freezera/Turbo Freezera nazwane potem Code3 czy Slight Freezer. Duży kawał roboty w tej materii poczynił oczywiście SoTe.
