Voir le sujet pr�c�dent :: Voir le sujet suivant |
Auteur |
Message |
toinet
Inscrit le: 15 Juin 2007 Messages: 326 Localisation: Paris, France
|
Post� le: Mer 08 Ao� 2007, 22:21 Sujet du message: Transat (No man's land, 1984) |
|
|
A French software from 1984, written by Jean-Marc Sornin. Come aboard, we're expecting you... Oops! Cross the Atlantic ocean from La Rochelle to Halifax. An old software written in Applesoft.
I have to admit that I have been unable to crack the software at the end of the 80's. Whatever I tried, it failed! I was close to stop working on that software until I tried the basic direct reading of the diskette through the RWTS...
PROTECTION TYPE
On a standard DOS 3.3 diskette:
- markers have been changed (D5 AA 96, F2 AA, AA/D5 D5/AA AD, F2 AA)
- data field routine changes depending on the track
- DOS 3.3 commands have been renamed or deactivated
BOOT TRACE
- 9600<C600.C6FFM
- 96FB: 4C 59 FF
- 9600G
Ah! we have a standard DOS 3.3 boot0 at $0800
- 96FB: A9 4C 8D 4A 08 A9 59 8D 4B 08 A9 FF 8D 4C 08 4C 01 08
- 9600G
Bingo, we have a RWTS from $B600 to $BFFF.
The RWTS entry point at $BD00 redirects to $BEC2. Then, depending on the track the head is over, the markers (DE or F2) and data read routine are changed then execution is given to $BD04.
At $BF24, we get the same inits found at $BEC2 but with no data read routine changes or whatever. That may interest us in a near future...
The data read routine at $BF75 reads the first markers from the drive (D5 AA AD or AA D5 AD), then it reads extra nibbles and finally read the standard 342 nibbles. Quite weird!
DISK COPY
As I have been unable to use Advanced Demuffin or similar products, I have written a short program at $0300 that performed track-per-track reads using the program RWTS and moves to my IIgs memory.
As the program is trivial, I will not detail it (read one track, copy to memory, loop until track $23)
As the RWTS is sort-of a standard one, I presume the code of the RWTS checks that its parameter table must be in $B7xx so that other disk copiers with their own table are unable to copy the disk. I see no other explanation.
PROTECTION REMOVAL
Now that the disk is copied, we must invalidate the call to the protection (the one that changes the data read routine and so on...), if you remember well:
- whenever you call $BD00, a JMP is performed at $BEC2
- at $BF24, we have a code equivalent to $BEC2 with no change in the data read routine.
=> Why don't we change the JMP $BEC2 with JMP $BF24 and try?
- Launch my favorite disk editor
- Read T0/S7
- At offsets $01/$02, change C2 BE with $24 BF
- Save and test...
Oh, my backup copy works well...
Toinet
nb. the CATALOG command has been renamed DIR... |
|
Revenir en haut de page |
|
![](templates/subSilver/images/spacer.gif) |
toinet
Inscrit le: 15 Juin 2007 Messages: 326 Localisation: Paris, France
|
Post� le: Ven 10 Ao� 2007, 9:16 Sujet du message: |
|
|
Tiens, tiens, en lisant la partie consacr�e au cracking & hacking du site, je suis tomb� sur la rubrique EDD IV et ses extra-bits.
La routine de lecture de Transat semble utiliser la m�me m�thode, j'y ai trouv� les m�mes
Code: | LDA $C08C,X
...
LDA $C08D,X
... |
Quelqu'un peut m'expliquer le r�le du $C08D ici, svp ? Pour le timing uniquement ?
Merci,
antoine |
|
Revenir en haut de page |
|
![](templates/subSilver/images/spacer.gif) |
Deckard
Inscrit le: 29 Mar 2007 Messages: 350 Localisation: Levallois-Perret / Le Mans
|
Post� le: Ven 10 Ao� 2007, 12:35 Sujet du message: |
|
|
toinet a �crit: |
Quelqu'un peut m'expliquer le r�le du $C08D ici, svp ? Pour le timing uniquement ?
|
Juste en compl�ment, c'est fait � quel moment par rapport � la d�composition d'un secteur (adresse, datas, gaps)?
Possible d'en voir un peu plus de cette routine de Transat ici?
Tu fais r�f�rence � �a j'imagine:
Code: |
MK8_XX LDA HC08C,X
BPL MK8_XX ; Marker 8 = $XX EDD l'ignore c'est le $FF trouv� par le programme EDDMK1
NOP
LDA HC08D,X ; Arghhhhh !!!!!!!
NOP
MK9_YY LDA HC08C,X
BMI MK9_YY ; Marker 9 = $XX EDD
; Pas un BPL mais un BMI, timing critique!
|
Ce que je peux d�j� te dire sans me tromper, c'est que c'est un cri qui fait peur - punaise, il me r�sonne encore dans les oreilles
Dans le contexte, c'est pour la d�synchro des 4 bits (timing) mais peut-�tre y a t il une ruse en plus (li�e au fonctionnement du LSS - je n'ai pas encore lu cette partie). L'expert va venir... ![Wink](images/smiles/icon_wink.gif)
Derni�re �dition par Deckard le Ven 10 Ao� 2007, 22:20; �dit� 1 fois |
|
Revenir en haut de page |
|
![](templates/subSilver/images/spacer.gif) |
JPL Site Admin
Inscrit le: 12 Mar 2007 Messages: 160 Localisation: Issy les Moulineaux / PARIS
|
Post� le: Ven 10 Ao� 2007, 17:23 Sujet du message: |
|
|
Deckard a �crit: | Juste en compl�ment, c'est fait � quel moment par rapport � la d�composition d'un secteur (adresse, datas, gaps)?
Possible d'en voir un peu plus de cette routine ici? |
C'est ce qui rend cette disquette particuli�rement vicieuse � copier car la protection est SUR CHAQUE PISTE (sauf la 0) JUSTE AVANT LES DATAS ET LE MALHEUREUX $F7 qui est le marker de r�f�rence, de plus le compte des 80 $FF est strict ce qui fait que les bitcopieurs essayent joyeusement de copier la piste � cet endroit qu'ils pensent �tre le d�but de piste, ce qui �videment vou� � l'echec. (pour le crack faut pas pousser c'est assez simple).
Voil� le sch�ma
La s�quence de d�synchronisation semble �tre la suivante
1111.1111 1100 1111.1100. 1111.0111 ce qui correspond � $FF !!!! $FC $F7
Le timing est effectivement tr�s critique et notre $CO8D,X enclenche la s�quence SR sur le LSS ce qui d'une part le repositionne en s�quence 0, et d'autre part passe la valeur 1 sur la position du bit 7 du data register (car la disquette est WP test�e d�s le d�but du boot EDD).
Le LSS se retrouve donc sur les s�quences de codes utilis�s quand MSB=1 ce qui permet ainsi au LDA qui est alors boucl� par BMI d'�liminer le second bit � 1 de la disquette voir avec + ou - un 0 selon la vitesse du drive. C'est le seul moyen d'�liminer ces deux bits 1 contenus dans le data register.
Apr�s le CLR de ce groupe de codes on se retrouvera alors normalement sur les s�quences du LSS quand MSB=0 et ainsi resynchronis� avec le LDA/BPL mais avec un p'tit souci que Utilico a bien compris...
Utilico ne teste pas la valeur du marker plac� juste derri�re la d�synchronisation � priori car il y a des difficult�s � savoir de fa�on certaine si apr�s le CLR on sortira de ces s�quences en allant vers la ligne A ou vers la ligne E des s�quences reprises pour MSB=0. L'incertitude est li�e � la vitesse des drives. (Ne surtout pas oublier que les bits 7 et 6 sont d�tect�s quand le data register n'est pas encore vid�). De ce fait en r�alit� on pourrait relire tout aussi bien 1111.1111 que 1011.1111 et on notera avec satisfaction que les deux zeros du $FC �crit juste avant le $F7 pourraient alors �tre vus comme des bits de synchro lors de la d�tection du marker $F7.
Ouf. |
|
Revenir en haut de page |
|
![](templates/subSilver/images/spacer.gif) |
|