[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need someone to do a little cracking



On 4 juin, 16:44, Nick Westgate <Nick.Westg...@gmail.com> wrote:
> On Jun 4, 11:31 am, Nick Westgate <Nick.Westg...@gmail.com> wrote:
>
> > Anyway, I will have a look at RSVP on the weekend.
>
> Well, I couldn't wait, and the volume FF was a red herring. I don't
> know too much about the internals of DOS, but apparently FF ends up
> being the same as 0. Pretty confusing the way it throws the volume
> number around.
>
> Anyway, you have mail.
>
> Just the simple patch below was applied.
> Of course, there may be other checks ...
>
> Cheers,
> Nick.
>
> BLOAD DDMOVER
> 8CE7G ; to decrypt
> 8C44:AD 05 8C A2 00 60 ; return A = last checked nibble value, X = 0
> (just in case)
> 870D:9A 8C ; set up to simulate the original jump through the stack
> UNLOCK DDMOVER
> BSAVE DDMOVER,A$8700,L$629
> LOCK DDMOVER

Another patch thanks to the correct images received from John.

BLOAD DDMOVER
8CE2 : 87
8CE5 : 3F
UNLOCK DDMOVER
BSAVE DDMOVER,A$8700,L1577
LOCK DDMOVER

But I prefer the Track/Sector/Offset manner:
TE/S9/E6:87 (was 8C)
TE/S9/E9:3F (was 99)

And, now, the boot trace...
C600 -> DOS 3.3 loads then launches HELLO which BRUNs DDMOVER

DDMOVER (loads at $8700, length is 1577 bytes)
8700 -> 870C -> 8CE1

8CE1 (the decryption routine)
- pushes 8C99 onto the stack
- decodes $8AFA..$8CFB
- and jumps (thanks to the stack) to $8C9A

8C9A (the protection routine)
- pushes 873F onto the stack
- performs the following calls: $8C14 then $8C3E
- updates somes values (especially the read error jump to the reboot
routine) then
- performs the following calls: $8C14 then $8C3E

8C14 (a RWTS read call)
- just sets the right parameters for our beloved IOB table

8C3E (a low-level $C0EC read routine) - FIRST CALL
- synchronizes (three $FF nibbles read)
- checks for the following parameters on the disk: D5 AA 96 FF FE AA
AA
- and the following ones also: AB AF

8C3E (a low-level $C0EC read routine) - SECOND CALL
- synchronizes (three $FF nibbles read)
- checks for the following parameters on the disk: D5 AA 96 FF FE AA
AB
- and the following ones also: AB AB

Oooooohhhh, it is a synchro protection. I read on track zero (AA AA) a
specific sector (AB AF) then I move to the next track (AA AB) and I
must get the AB AB sector (please forgive me, I do not have my 4*4
table with me, therefore find the decimal sector value yourself) If I
read the right value, then I have the original disk. If not, I have a
copy...

And now, what should I do?
On the original disk, the values returned are: X: unknown, A: $FBB3
value, Y: $00
What we could do is tell the software to jump to the pre-protection
routine but to avoid the jump to the real protection routine. That is
what my 2 bytes change is about: I force the jump to $873F in the
decypher routine at $8CE1.

There are plenty of other methods to bypass the protection routine,
Nick's post was one of those and I am pretty sure a 1 byte change
could be done. No other protection or check routines found on the
disk. The program seems to be compiled.

Thank you John, that was a funny one. And I do not encounter any
issues just like Nick.

Antoine "LoGo" Vignau