Dobry Wieczór!
W celach "naukowych"... a tak naprawdę z czystej ciekawości postanowiłem się trochę dłużej zająć tym problemem, przeglądając te wszystkie łatwo dostępne pliki .cas zawierające ten loader, tzn:
Super Cobra - od QTZ
Universal Hero - od Krapa
Spy vs Spy - z archiwum AoL
Ixion2 - z archiwum AoLOkazało się (czego już nie pamiętałem) że TurboCopy 3/4 dodatkowo XOR-ował strumień danych przed zapisem na taśmie, był to co prawda prymitywny XOR z jedną wartością, ale wygląda na to że wartość ta była losowana przy zapisie każdego pliku. Wartość XOR była zachowana w kodzie loadera aby ten mógł bezproblemowo odkodować strumień wejściowy.
Tak jak pisał QTZ pliki zawierają na końcu niepotrzebne zera, nie wiem czy to powstało przy konwersji do CAS, czy też było tak na taśmie nagrane, jednak faktem jest że te zera są w każdym z tych plików obecne.
W ramach nauki czegoś nowego postanowiłem napisać prosty kod/skrypt w Pythonie który potrafi taki strumień danych z TurboCopy 3/4 odkodować i przywrócić go do pierwotnej postaci. Dla chętnych źródła są tutaj: TCX Tools.
Na potrzeby tej całej "zabawy" i aby nie komplikować sobie życia poprzez pisanie dodatkowego kodu do obróbki plików CAS, wymyśliłem sobie format TCX który zawiera już binarny stream wyciągnięty z pliku CAS. Do konwersji używałem programu a8-conver z pakiety a8cas od szanownego kolegi Krótkiego.
Jak przebiegał proces konwersji? Konwertowałem plik cas na hex, czyli np:
a8cas-convert -fh spy_vs_spy.cas spy_vs_spy.hexpo czym dokonywałem ręcznej edycji pliku HEX:
A8CAS-HEX
FUJI
baud 00603
data 19205 55 55 fc 00 06 00 07 2a 07 a2 00 a0 00 fe 2b 07 51 04 59 00 04 48 b9 00 04 99 00 0a 68 e8 c8 d0 ec 8d fc bf ee fc bf cd fc bf d0 02 38 60 a8 30 8c 2f 01 a8 08 8c 30 01 ac fb be 8c 29 08 a1 07 9f a8 1f a3 07 a1 fe 85 47 e7 8d c5 01 8d c7 01 8d 43 01 85 13 a4 13 c8 0f cf f9 e7 85 08 ac b7 08 c8 73 cf 19 1f 0a 08 8c e0 01 a8 2a 8c df 01 1f 7e 06 1f a1 06 1f 95 07 1f 01 08 1f 2a 07 4b 73 e3 a1 eb ; standard record; length=132, checksum=eb OK
data 00264 55 55 fc 0f a8 02 9c 41 02 a8 03 9c 49 02 a8 24 9c 43 02 a8 08 9c 44 02 a8 7f 9c 4a 02 a8 11 8c fb 01 4b 55 e3 1f 3b 07 ac ee 01 cc 82 06 cf ce a4 13 c4 13 ef f9 1f 52 07 a4 42 8c 79 06 a4 43 8c 7a 06 9f ff 1f 0b 07 c8 be cf 0e 1f 0b 07 a9 a8 ff 1f eb 06 c9 cf f9 4b e8 06 c8 ce cf 09 1f 0b 07 a9 1f 0b 07 4b ce 06 1f eb 06 4b bf 06 9f ff 90 42 47 e5 42 cf 01 e5 43 a4 42 c4 44 a4 43 e4 45 8f 80 ; standard record; length=132, checksum=80 OK
data 00264 55 55 fc 28 67 67 67 1f 52 07 2f 21 4b bf 06 89 84 48 a1 0f a8 ff 9c 47 02 9c 48 02 a8 06 9c 41 02 1f 55 e3 2f 09 4c 2b 07 47 a4 48 a9 67 60 af bd 43 04 c9 88 d0 0f 20 96 08 68 68 a0 80 60 a9 ed 48 a9 3c 48 60 a9 53 8d 3b 09 a9 09 8d 3c 09 20 96 08 4c 50 08 20 90 08 20 08 09 20 0c 08 85 43 20 0c 08 85 44 a9 ff c5 44 d0 04 c5 43 f0 e6 a9 fe 85 48 20 0c 08 85 45 c9 e3 d0 02 e6 48 20 0c 08 85 ea ; standard record; length=132, checksum=ea OK
data 00264 55 55 fc 46 c9 02 d0 02 e6 48 e6 45 d0 02 e6 46 a0 00 60 a0 3c 8c 02 d3 60 a2 10 a9 0c 9d 42 03 20 56 e4 a2 e4 a0 5f a9 06 4c 5c e4 ee c4 02 ad c4 02 8d 16 d0 ce 28 09 d0 11 a9 04 8d 28 09 ad c7 02 18 69 10 8d c7 02 8d 19 d0 46 4d ae 29 09 ca 10 29 ee 4e 09 d0 03 ee 4f 09 ad 4e 09 c9 81 d0 18 ad 4f 09 c9 0a d0 11 a9 8f 8d 4e 09 a9 09 8d 4f 09 bd 2b 08 c9 3f d0 f9 a2 07 8e 29 09 8e 04 d4 4c 21 ; standard record; length=132, checksum=21 OK
data 00264 55 55 fc 5f e4 6c e0 02 6c e2 02 20 05 09 a9 2b 8d e2 02 a9 08 8d e3 02 a6 48 30 0b a0 34 20 92 08 86 14 c4 14 d0 fc 60 43 3a 9b 04 07 ff 52 4b 31 39 38 37 70 70 70 70 70 70 70 70 70 46 67 09 70 70 70 70 70 47 7b 09 70 70 70 70 70 70 70 70 56 8f 09 41 31 09 00 00 00 00 00 ec ef e1 e4 00 e5 f2 f2 ef f2 00 00 00 00 00 00 00 24 34 02 37 21 32 33 02 23 25 2e 34 32 35 2d 02 00 00 00 0a 00 33 30 cf ; standard record; length=132, checksum=cf OK
data 00264 55 55 fc 39 00 36 33 00 33 30 39 00 29 29 29 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 73 74 75 64 69 6f 40 6b 6f 6d 70 75 74 65 72 6f 77 65 40 64 74 4e 40 02 37 21 32 33 02 00 61 6e 74 72 65 73 6f 6c 61 40 6f 66 65 72 75 6a 65 40 5a 40 64 75 7a 79 40 77 79 62 6f 72 40 70 72 6f 67 72 61 6d 6f 77 40 4c 40 69 6e 73 74 72 75 6b 63 6a 69 40 69 40 6c 69 74 65 72 61 3c ; standard record; length=132, checksum=3c OK
data 00263 55 55 fc 74 75 72 79 40 66 61 63 68 6f 77 65 6a 4e 00 00 0a 00 eb e1 f4 e1 ec ef e7 e9 40 e7 f2 e1 f4 e9 f3 40 0a 00 f7 f9 f3 f9 ec eb e1 40 f0 ef e3 fa f4 e1 40 0a 00 00 3a 21 30 21 2d 29 25 34 21 2a 00 4d 40 64 74 4e 40 02 23 25 2e 34 32 35 2d 02 00 4d 00 02 37 21 32 33 02 00 40 50 50 4d 50 51 57 40 77 4d 77 61 40 75 6c 4e 40 6d 61 72 73 7a 61 6c 6b 6f 77 73 6b 61 40 51 50 54 00 00 00 00 f3 ; standard record; length=132, checksum=f3 OK
baud 01190
data 15437 55 55 ff 20 36 01 ; standard record; length=6, checksum=01 OK
baud 00603
data 00346 55 55 fc 50 50 99 0f e0 0e 60 ac df e1 ff 0e 60 f2 a1 e1 af 1f 60 ce a1 ee 99 0f 10 ff af a9 8f a9 06 99 22 9f ad 06 0f 22 9e ad 8f 8f 5b 06 3b 22 69 ad 06 65 22 6a ad 06 87 22 6b ad cf 10 ab 4d ad 4c ad af a9 ff 0e e0 10 10 51 10 88 2f 10 88 2f 10 89 ad 2f 10 89 ad 2f 10 89 a5 2f 10 89 a5 2f 10 8a 60 ac 05 0f ba bb fa ae fa fa ba 60 a0 fa ef 10 a2 a5 05 05 0f fa bb fa ea fa fa ba 60 a0 fa 2a ; standard record; length=132, checksum=2a OK
data 02853 55 55 fc ef 10 a2 ad 05 05 af fa bb fa ea fa fa ba 60 a0 fa ef 10 a1 05 07 af ff bb fe ea af bb 10 b1 ad 05 0f af ff bb fe ea ff bb 10 b1 ad 05 60 ae 10 53 fe bb fa ae fb bb 60 bf 50 6f 10 a2 a5 2d 60 ae 10 53 fe bb fa af bb bb 60 bf 50 6f 10 a2 a5 af 50 53 fe bb fa fa fb bb 60 bf 50 6f 10 a2 87 af 53 af ff bb fe fa fb bb 10 8f 53 af ff bb ff fa ff bb 10 8f 93 10 8a aa fa 90 90 50 6f 50 ac 4a ; standard record; length=132, checksum=4a OK
data 02856 55 55 fc 50 10 b0 aa fa e0 90 50 6c 50 6c 50 6f 10 b1 ba fa e0 60 ae 60 50 6c 50 6c 50 5f 10 b1 ba af ac 6f 5f a0 6c 5c 6c 5f 10 b1 ba af ac 5f 5f a0 6c 5c 6f 5f 10 b1 aa 10 ad 5f 5f a0 af 5c 6f 5f 10 ba ad 85 8f a7 60 ac 07 10 ad aa ef af 53 5f a0 af 5c 6c 5f 10 ba a7 8f a7 a7 27 07 a7 10 ad ae ef af 93 5f a0 af 5c 50 5f 10 ba a7 8f a7 a7 07 27 a7 10 ad ae ff af 93 5f a0 50 5c 50 6f 10 ba 18 ; standard record; length=132, checksum=18 OKręczna modyfikacja polegała na usunięciu rekordów loadera i 6-bajtowego rekordu zabezpieczającego nagranie przed skopiowaniem przez zwykłe kopiery, a więc po wycięciu loadera (pierwsze 7 standardowych rekordów) i 6 bajtowego rekordu "psującego zapis" zostawało coś takiego:
A8CAS-HEX
FUJI
baud 00603
data 00346 55 55 fc 50 50 99 0f e0 0e 60 ac df e1 ff 0e 60 f2 a1 e1 af 1f 60 ce a1 ee 99 0f 10 ff af a9 8f a9 06 99 22 9f ad 06 0f 22 9e ad 8f 8f 5b 06 3b 22 69 ad 06 65 22 6a ad 06 87 22 6b ad cf 10 ab 4d ad 4c ad af a9 ff 0e e0 10 10 51 10 88 2f 10 88 2f 10 89 ad 2f 10 89 ad 2f 10 89 a5 2f 10 89 a5 2f 10 8a 60 ac 05 0f ba bb fa ae fa fa ba 60 a0 fa ef 10 a2 a5 05 05 0f fa bb fa ea fa fa ba 60 a0 fa 2a ; standard record; length=132, checksum=2a OK
data 02853 55 55 fc ef 10 a2 ad 05 05 af fa bb fa ea fa fa ba 60 a0 fa ef 10 a1 05 07 af ff bb fe ea af bb 10 b1 ad 05 0f af ff bb fe ea ff bb 10 b1 ad 05 60 ae 10 53 fe bb fa ae fb bb 60 bf 50 6f 10 a2 a5 2d 60 ae 10 53 fe bb fa af bb bb 60 bf 50 6f 10 a2 a5 af 50 53 fe bb fa fa fb bb 60 bf 50 6f 10 a2 87 af 53 af ff bb fe fa fb bb 10 8f 53 af ff bb ff fa ff bb 10 8f 93 10 8a aa fa 90 90 50 6f 50 ac 4a ; standard record; length=132, checksum=4a OK
data 02856 55 55 fc 50 10 b0 aa fa e0 90 50 6c 50 6c 50 6f 10 b1 ba fa e0 60 ae 60 50 6c 50 6c 50 5f 10 b1 ba af ac 6f 5f a0 6c 5c 6c 5f 10 b1 ba af ac 5f 5f a0 6c 5c 6f 5f 10 b1 aa 10 ad 5f 5f a0 af 5c 6f 5f 10 ba ad 85 8f a7 60 ac 07 10 ad aa ef af 53 5f a0 af 5c 6c 5f 10 ba a7 8f a7 a7 27 07 a7 10 ad ae ef af 93 5f a0 af 5c 50 5f 10 ba a7 8f a7 a7 07 27 a7 10 ad ae ff af 93 5f a0 50 5c 50 6f 10 ba 18 ; standard record; length=132, checksum=18 OK
...tak zmodyfikowany plik HEX konwertowałem ponownie do pliku CAS:
a8cas-convert spy_vs_spy.hex spy_vs_spy_ldr_removed.casi taki plik CAS, przy użyciu emulatora z odpalonym MyDOS-em, urządzeniem "H:" kopiowałem do postaci binarnej, którą sobie nazwałem .TCX (od Turbo Copy eXecutable).
Teraz mogłem sobie eksperymentować bawiąc się pisaniem bzdur w Pythonie. Na początku chciałem to zrobić jak QTZ, czyli Turbo Basic XL, emulator ustawiony na 21MHz, SIO/CIO patch czytanie bezpośrednio z C: zapis obrobionych danych na H: byłoby pewnie prościej i szybciej... ale postanowiłem się pobawić, trochę rozruszać mózg i nauczyć się czegoś nowego, a że w Pythonie nigdy nie napisałem więcej niż kilkanaście linii... w dodatku nie chciało mi się implementować jakiejś obsługi błędów... i mieć efekty szybki i sprawdzalne od razu, to wybór padł na Pythona... szybkie to być nie musi, Python jest interpreterem więc wszystko można było mieć pod reką... można powiedzieć że to taka obiektowa dość nowoczesna wersja BASIC-a (hahah... już widzę jak mnie ludzie od Pythona zaraz zjedzą :P ja się nie nim nie znam, więc mogę sobie pozwolić na mówienie takich herezji :P)
Z "Super Cobra" szybko poszło, ale potem się okazało że Super Cobra od QTZ ma zmodyfikowany loader (nie oczekuje na ten mały 6 bajtowy rekord, ktoś tam wstawił trochę nop-ów) a także nie ma XOR-owania streamu danych. Pozostałe pliki miały owe "zabezpieczenie" oraz dodatkowo zapisane dane były potraktowane XOR-em z losową wartością zależną od pliku.
Napisanie tego lame-dekodera zajęło mi parę godzin, oczywiście ze sporymi przerwami bo miałem niestety inne rzeczy do roboty, ale większość tego czasu to była nauka tego pythona... nie chciało mi się w C klepać, to mam za swoje :P
Kod dekodera można uruchomić zarówno pod Linux jak i Windows, nie wymaga żadnej kompilacji po prostu należy go wywołać z command-line, okna terminala, etc.
Pisałem wyżej o XOR-owaniu danych przez program TurboCopy3/4... jak się zatem dobrać do klucza skoro wyżej pokazałem jak wywalić loader, a klucz byl w loaderze? Ponieważ XOR jedno-bajtową wartością to żadne zabezpieczenie nie jest, a my znamy w dodatku nagłówek jakiego się należy spodziewać w danych to klucz możemy "zgadnąć", tzn. obliczyć go sobie i program tak też czyni... jeżeli podany plik TCX nie ma odpowiedniego nagłówka program sprawdza strukturę danych i wypisuje klucz:
sbn@debian:~/test$ python3 tcx_rle_decoder.py universal_hero.tcx
Input file is universal_hero.tcx and the file size is 41088 bytes.
TCX data loaded, checking data...
Header is: $4b4b
Not a Atari DOS file header! Wrong file type? Data encrypted?
Maybe the XOR key for data decoding is wrong or not given?
>>> But if I can guess try this XOR key value: 0xB4 <<<gdy zatem już mu podamy ten klucz, to zajmie sie on już resztą i wygeneruje zdekodowany plik samodzielnie, przy okazji wypisując strukturę pliku:
sbn@debian:~/test$ python3 tcx_rle_decoder.py universal_hero.tcx 0xb4
Input file is universal_hero.tcx and the file size is 41088 bytes.
TCX data loaded, checking data...
Header is: $ffff
block 000: $0586-$06fe
block 001: $02e2-$02e3
block 002: $0c00-$bffe
block 003: $02e0-$02e1
!!! WARNING !!! Bad header data was detected, skipped 87 garbage byte(s).
Input data processing done, 4 block(s) processed, generating output file...
Output file is universal_hero.tcx.xex and the file size is 46478 bytes.
Processing done, output file written, IN/OUT file size diff is 5390 byte(s).Jeżeli zapytacie po cholerę ten cały cyrk z "projektem" składającym się kilkudziesięciu linii w Pythonie i wrzucaniem tego na github, etc. To pomyślałem sobie że jeżeli będzie potrzeba, zainteresowanie, ew. jakieś nowe pliki do przetworzenia, to może z czasem rozbuduje ten projekt. Napiszę konwerter CAS<-->TCX, wrzucę de-assemblowane źródła loadera, a może nawet jakby było sporo takich kaset do zgrania u kogoś, to może pokuszę się o napisanie programu kopiującego do tego typu nagrań bezpośrednio na Atari. Pytanie tylko czy jest tyle tego typu kaset/plików aby poświęcać temu czas?
A i na koniec gdyby ktoś chciał zebraną w jedno miejsce kolekcję plików CAS,TCX i XEX aby pobawić się tym wszystkim sememu to proszę bardzo: TCX Tools test file set.
Krap, QTZ dzięki WIELKIE za udostępnienie tych plików.
ps) @QTZ ... Supaplex ma rację... nagłówków pliku file nie uwzględniamy w przy kompresji/dekompresji (przynajmniej tak to czyni kod loadera, tzn. nagłówki segmentów danych czyta niezależnie, za dekompresję bierze się dopiero jak czyta napływające bajty z aktualnie wczytywanego segmentu danych). Kompresji RLE podlegają tylko dane które są w danym segmencie danych zawarte. Loader dekompresuje dane bardzo szybko, więc nie ma potrzeby robić długich przerw między rekordami. Turbo Copy 3/4 wydłużał przerwę między rekordami jedynie wtedy gdy wykrył że w danym rekordzie danych znajduje się segment INIT ($2e2-$2e3) robił to dlatego że przed skokiem do INIT zatrzymywał silnik magnetofonu, bo nigdy nie było wiadomo ile czasu spędzi CPU w kodzie uruchomionym przez INIT, być może będzie to ułamek sekundy, a może to będzie jakieś intro które będzie oczekiwało na wciśnięcie klawisza?
