Autor Wątek: Jakość wersji hackerskich  (Przeczytany 5993 razy)

cherkasy

  • *
  • Wiadomości: 12
  • Miejsce pobytu:
    Ukraina, Cherkasy
Odp: Jakość wersji hackerskich
« Odpowiedź #45 dnia: 2021.01.22, 12:06:36 »
Nasi hakerzy demontujący programy ładujące widzieli fragmenty kodu po polskich hakerach (nasze przerobione wersje dla TR-Dos)

Maryjan

  • *****
  • Wiadomości: 6666
  • Miejsce pobytu:
    Skarżysko-Kam.
  • Scotch whiskey and West Highland Terrier
Odp: Jakość wersji hackerskich
« Odpowiedź #46 dnia: 2021.01.22, 13:56:12 »
Dobre, dobre :)

Obrazuje to jak i skąd płynęło oprogramowanie w kierunku wschodnim.
"Co miałem powiedzieć - przeczytałem..." Nikodem Dyzma

Boyo

  • *****
  • Wiadomości: 751
  • Miejsce pobytu:
    Warszawa
Odp: Jakość wersji hackerskich
« Odpowiedź #47 dnia: 2021.01.22, 15:33:29 »
Zawsze się zastanawiałem jak działało to "hackowanie" przy pomocy tzw. "przystawek".
Za dawnych czasów miałem Masterface, a obecnie całe spektrum Multiface-like interface'ów.
Może tu się mylę, ale wszystkie tego rodzaju sprzęty mają wyłącznie możliwość zgrywania całej pamięci komputera na taśmę, microdrive itp.
Ale to tylko "mniejsza" część pracy. Trzeba sporządzić screen i loader w basicu.
Dodatkowo były przecież dostępne pirackie gry, posiadające kilka bloków kodu.
A co z "hackowaniem" gier z poziomami, jak to funkcjonowało?
« Ostatnia zmiana: 2021.01.22, 15:43:15 wysłana przez Boyo »
ZX81 / 2x ZX Spectrum 48kB / 3x ZX Spectrum+ 48kB / Inves Spectrum+ / ZX Spectrum+ 128kB / 2x ZX Spectrum +2 / ZX Spectrum +2A Action Pack / ZX Spectrum +3 / Didaktik Gama / TC 2048 / 2x JustSpeccy 128K
A500 2,5MB RAM Gotek HxC / A1200 Blizzard 1220/4+ADD4

trojacek

  • *****
  • Wiadomości: 6846
  • Miejsce pobytu:
    Warszawa
Odp: Jakość wersji hackerskich
« Odpowiedź #48 dnia: 2021.01.22, 16:49:01 »
Zawsze się zastanawiałem jak działało to "hackowanie" przy pomocy tzw. "przystawek".

Mogę trochę poteoretyzować, bo crackowaniem gier się nie zajmowałem, natomiast przeniosłem trochę gier na dyski, więc tak czy siak musiałem mieć do czynienia z rozmaitymi dziwacznymi loaderami ;)

Cytuj
Za dawnych czasów miałem Masterface, a obecnie całe spektrum Multiface-like interface'ów.
Może tu się mylę, ale wszystkie tego rodzaju sprzęty mają wyłącznie możliwość zgrywania całej pamięci komputera na taśmę, microdrive itp.

Owszem, ale prawdę mówiąc, crackowanie wszystkich gier przez NMI to raczej jakiś akt rozpaczy czy bezradności ;). Ewentualnie wynik pośpiechu. Jeśli gra nie miała zabezpieczenia typu Lenslok (pryzmaty) lub wklepywania literek ze wskazanej kratki na dołączonym kartoniku, to zwykle wystarczała analiza loadera i zablokowanie ostatecznego uruchomienia kodu gry.
Przede wszystkim, istnieją narzędzia do analizy pierwotnego loadera - choćby polski OPENER, który pozwalał uniknąć autostartu i dać szansę na przeanalizowanie zawartości loadera, wyłączając przy okazji wszelkie sztuczki blokujące listowanie i modyfikowanie programu (linia 0, biały INK i PAPER itp.).
Jeśli loader był w całości w Basicu - to nie było co kombinować, bo wszystkie bloki kodu były ładowane komendą LOAD ... CODE. Czyli dowolny kopier był je w stanie przegrać, można też było ręcznie zapisywać wgrane bloki poprzez SAVE.
Zwykle jednak loader składał się z polecenia uruchomienia kodu maszynowego (np. RANDOMIZE USR ...) oraz z linijki zaczynającej się od komendy REM, a po niej ukryty kod maszynowy, widziany jako krzaczki. A to mogło oznaczać, że procedura ładowania z taśmy jest "customowa" - na przykład bez nagłówków, albo z inną prędkością, albo jakimś XOR-owaniem bitów, albo efekciarsko - bez pasków na borderze, tylko z paskami w małym okienku lub z animowanym "licznikiem taśmy".
Tu warto wspomnieć polski program COPY-COPY, który pozwalał wgrywać pliki bez nagłówków i zapisywać jest w standardowym formacie :)
Zrozumienie kodu maszynowego loadera pozwalała zwykle zablokować uruchomienie gry i zgrać wczytane bloki. Zwykle, ale... nie zawsze.
Wyjątkiem od wszelkich reguł były gry w monobloku o rozmiarze niemal (lub dokładnie) 48 KB. Loader składał się z jednej komendy LOAD "" CODE i... to wszystko. W tym jednym bloku kodu był screen, zmienne systemowe, program w Basicu, kod gry oraz zawartość stosu. I tu już ciężko coś było zrobić bez żmudnej analizy kodu, zwłaszcza w czasach, kiedy nie można sobie było siąść do PC, odpalić emulator i analizować program krokowo, albo otworzyć plik TAP w hexedytorze (o ile kod nie został zaszyfrowany). I wtedy NMI był najprostszą opcją.

Cytuj
A co z "hackowaniem" gier z poziomami, jak to funkcjonowało?

Jeśli format na taśmie był standardowy lub tylko bez nagłówka, to żaden problem - wystarczał COPY-COPY.
Jeśli format był własny - trzeba było znaleźć procedurę jego obsługi i ładować po jednym bloku i potem zapisywać. Oczywiście, w kodzie "złamanej" gry trzeba było zmienić procedury taśmowe na te z ROM-u.

Mam nadzieję, że trzyma się to kupy, co napisałem. COPY-COPY i OPENERA to ostatni raz widziałem z ćwierć wieku temu ;)

cherkasy

  • *
  • Wiadomości: 12
  • Miejsce pobytu:
    Ukraina, Cherkasy

trojacek

  • *****
  • Wiadomości: 6846
  • Miejsce pobytu:
    Warszawa

Boyo

  • *****
  • Wiadomości: 751
  • Miejsce pobytu:
    Warszawa
Odp: Jakość wersji hackerskich
« Odpowiedź #51 dnia: 2021.01.22, 19:03:15 »
Brzmi to jak żmudna robota, Bill musial byc cierpliwy. Openera kojarze.
Bytes: LOAD BASIC STOP AND LIST
Czasami działała komenda MERGE "" aby wgrać i zastopowac program w Basicu :)
« Ostatnia zmiana: 2021.01.22, 19:09:42 wysłana przez Boyo »
ZX81 / 2x ZX Spectrum 48kB / 3x ZX Spectrum+ 48kB / Inves Spectrum+ / ZX Spectrum+ 128kB / 2x ZX Spectrum +2 / ZX Spectrum +2A Action Pack / ZX Spectrum +3 / Didaktik Gama / TC 2048 / 2x JustSpeccy 128K
A500 2,5MB RAM Gotek HxC / A1200 Blizzard 1220/4+ADD4

trojacek

  • *****
  • Wiadomości: 6846
  • Miejsce pobytu:
    Warszawa
Odp: Jakość wersji hackerskich
« Odpowiedź #52 dnia: 2021.01.22, 19:24:50 »
Czasami. MERGE można było jakoś zablokować, jak również możliwość przerwania programu.
Były sztuczki na wszystko, i sztuczki przeciw tym sztuczkom :)

Ilyad

  • *****
  • Wiadomości: 580
  • Miejsce pobytu:
    Białystok, IV Rzesza Pospolita
Odp: Jakość wersji hackerskich
« Odpowiedź #53 dnia: 2021.01.22, 21:44:29 »
Czasami działała komenda MERGE "" aby wgrać i zastopowac program w Basicu :)
Pamiętam że ladery Billa były przed tym zabezpieczone. Podobnie SS Captaina i Tarzan Boya
ZX-81, ZX-Pand AY, 48k "gumiak", 48K+, 128K + "Toster", +2 "szarak" 1024k Profi, Masakrator FM, DivIDE 2K11, ZX Evolution rev. C, ZX-Uno, C64, C16 64K, Plus4 + 1541 Ultimate II + SD2IEC

matofesi

  • *****
  • Wiadomości: 2049
  • Miejsce pobytu:
    Toruń/Poland
Odp: Jakość wersji hackerskich
« Odpowiedź #54 dnia: 2021.01.22, 23:13:18 »
Zabezpieczenie przed MERGE było stosunkowo proste - nie pamiętam już dokładnie z czego to wynikało, ale należało dodać na koniec programu linię zawierającą np. REM, potem namierzyć jej adres w pamięci i przePOKE'ować oba bajty numeru linii na 255. Kod w ROMie przy MERGEowaniu głupiał, bo oczywiście numer linii mu nie pasował i szedł w kartofle wieszając system.
Obejście, które robią różne "odblokowywacze" polegało na skopiowaniu kawałka kodu obsługującego procedurę LOAD z ROMu z pominięciem trzech instrukcji ustawiających linię autostartu.

trojacek

  • *****
  • Wiadomości: 6846
  • Miejsce pobytu:
    Warszawa
Odp: Jakość wersji hackerskich
« Odpowiedź #55 dnia: 2021.01.22, 23:21:36 »
No właśnie moje myśli szły tym tropem. Ważne numery linii w Basicu są z przedziału 1-9999. Zakładałem, że linia nr 0 wykrzaczy procedurę MERGE. Ale widać nie - numer musi być większy od 9999.
Procedura MERGE sprawdza numery linii, ponieważ oryginalnie komenda ta służy do łączenia programów w Basicu, na podstawie numerów linii. Można więc łączyć programy, o ile numeracja linii się w nich nie pokrywa. Jeśli "nowy" program ma numer, który już wcześniej istniał, to stara linia jest zastępowana nową.

redhawk

  • **
  • Wiadomości: 79
Odp: Jakość wersji hackerskich
« Odpowiedź #56 dnia: 2021.01.23, 18:39:17 »
Wiecie, niektórzy pragną zapomnieć przeszłość swojej młodości, bo zaczyna to wpływać na ich życie zawodowe.
A ten pan nie ma nic do ukrycia :) https://www.eurogamer.net/articles/2013-11-06-seeing-red-the-story-of-cd-projekt

tooloud

  • *****
  • Wiadomości: 3188
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: Jakość wersji hackerskich
« Odpowiedź #57 dnia: 2021.01.24, 01:16:20 »
No właśnie moje myśli szły tym tropem. Ważne numery linii w Basicu są z przedziału 1-9999. Zakładałem, że linia nr 0 wykrzaczy procedurę MERGE. Ale widać nie - numer musi być większy od 9999.
Procedura MERGE sprawdza numery linii, ponieważ oryginalnie komenda ta służy do łączenia programów w Basicu, na podstawie numerów linii. Można więc łączyć programy, o ile numeracja linii się w nich nie pokrywa. Jeśli "nowy" program ma numer, który już wcześniej istniał, to stara linia jest zastępowana nową.

linii z numerem 0 nie da się wprowadzić ot tak, bo próba wpisania:

0 PRINT "test"

da w rezultacie

C Nonsence in BASIC, 0:1

ale jeżeli zrobimy:
1 PRINT "test"
a potem
POKE 23755,0: POKE 23756,0
to zmienimy numer linii z 1 na 0 :)

Taka linia nie daje się w prosty sposób modyfikować, więc umieszczano w niej "copyrights".

edit: a "CLOSE #0" blokowało bodajże dostęp do dwóch dolnych linii :)
dużo sprzętu mało czasu.

matofesi

  • *****
  • Wiadomości: 2049
  • Miejsce pobytu:
    Toruń/Poland
Odp: Jakość wersji hackerskich
« Odpowiedź #58 dnia: 2021.01.25, 09:06:24 »
edit: a "CLOSE #0" blokowało bodajże dostęp do dwóch dolnych linii :)

Co nie miało strategicznego znaczenia jeśli loader dało się wczytać przez MERGE albo którymś z programików do wczytywania bez autostartu. Jeśli kod się załadował i nie wystartował to można go było podejrzeć itp. Dlatego pisałem, że o ile pamiętam był jakiś trick, który pozwalał wywalić system jak się wylistowało kod - któryś z błędów w ROMie pozwalał zmontować sekwencję, która przy wyświetlaniu na ekran wieszała system albo jakoś tak.

tooloud

  • *****
  • Wiadomości: 3188
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: Jakość wersji hackerskich
« Odpowiedź #59 dnia: 2021.01.25, 12:52:40 »
to z CLOSE#0 oczywiście da się pominąć, ale jak ktoś nie znał tego patentu z linią 0, to nie był w stanie jej skasować, a wystarczy wrzucenie do niej na końcu REM z ukrytą maszynówką wywołującą jakieś specyficzne ładowanie binarki (np. binarka w postaci następnego segmentu jest bez 2-3 bajtów na początku, które wcześniej są dopisywane z tego REM po wywołaniu procki). Pełne pole do zabawy :)
dużo sprzętu mało czasu.