Re: Need someone to do a little cracking

[sirghoul@optonline.net]

I took a copy of my uncracked image, and tried both Nick's and Antoine's patches.

Both worked fine. Apparently, somewhere between Nick sending, and me receiving his cracked image, something got
messed-up.

Heck, I'll even say it might have happened on my end <grin>.

Anyway, thanks to both of you for working on this. I'm going to put together the docs and upload this one to asimov and
Garberstreet.

John.

On Tue, 16 Jun 2009 13:28:23 -0700 (PDT), Toinet <antoine.vignau@laposte.net> wrote:

>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

Little Birdie In The Sky....

Why'd you do that in my eye??

I won't holler, I won't cry......

I'm happy elephants can't fly!!