Need someone to do a little cracking
sirg...@optonline.net
Converted the disk to normal dos with the b942/be48/copya routine. Boots cleanly, but there seem to be at least 2 disk
check routines:
1 in the file ddmover
1 in the file main.
Anyone want to take a crack at this??
download the images from:
http://www.sendspace.com/file/7vy5nt
John.
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!!
Michael J. Mahon
> I have an original of the program RSVP that I've been trying to convert to .dsk
>
> Converted the disk to normal dos with the b942/be48/copya routine. Boots cleanly, but there seem to be at least 2 disk
> check routines:
>
> 1 in the file ddmover
>
> 1 in the file main.
>
> Anyone want to take a crack at this??
>
> download the images from:
>
> http://www.sendspace.com/file/7vy5nt
FWIW, the DDMOVER program contains a decryption routine at $8CE1 that
does a "running" or "chain" EOR to decrypt the code stored at $8AFA to
$8BFB.
Patching the RTS at $8D26 to BRK and running the code will reveal
the decrypted code.
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
sirg...@optonline.net
>sirg...@optonline.net wrote:
>> I have an original of the program RSVP that I've been trying to convert to .dsk
>>
>
>FWIW, the DDMOVER program contains a decryption routine at $8CE1 that
>does a "running" or "chain" EOR to decrypt the code stored at $8AFA to
>$8BFB.
>
>Patching the RTS at $8D26 to BRK and running the code will reveal
>the decrypted code.
>
>-michael
<grin> All of which is beyond my skills. I can follow along in an explanation, and perform the part where it says 'copy
this to here, make these changes, viola!!'.
I've disabled a few boot-up crackscreens by finding the jump to the unpacking code, and the infinite wait-for-a-keypress
loop, but RWTS?? mostly Greek to me.
Michael J. Mahon
> On Mon, 01 Jun 2009 23:29:14 -0700, "Michael J. Mahon" <mjm...@aol.com> wrote:
>
>> sirg...@optonline.net wrote:
>>> I have an original of the program RSVP that I've been trying to convert to .dsk
>>>
>
>> FWIW, the DDMOVER program contains a decryption routine at $8CE1 that
>> does a "running" or "chain" EOR to decrypt the code stored at $8AFA to
>> $8BFB.
>>
>> Patching the RTS at $8D26 to BRK and running the code will reveal
>> the decrypted code.
>>
>> -michael
>
> <grin> All of which is beyond my skills. I can follow along in an explanation, and perform the part where it says 'copy
> this to here, make these changes, viola!!'.
>
> I've disabled a few boot-up crackscreens by finding the jump to the unpacking code, and the infinite wait-for-a-keypress
> loop, but RWTS?? mostly Greek to me.
No RWTS required!
Just BLOAD DDMOVER and patch $8D26 to $00 (BRK), then 8CE1G.
The machine will "break" almost immediately, then you can examine the
code (and data) in the region $8AFA..$8BFB and I can guarantee that you
will see what it does to signature check the disk. (Of course, that
means accessing the disk, so there things may get more technical.)
With any luck, you can just patch the entry point to CLC/RTS ($18 $60)
and the program will assume that the check was passed, but that's only
speculation--I haven't looked at the code myself, either. ;-)
Nick Westgate
> The machine will "break" almost immediately, then you can examine the
> code (and data) in the region $8AFA..$8BFB and I can guarantee that you
> will see what it does to signature check the disk. (Of course, that
> means accessing the disk, so there things may get more technical.)
Yes, this (!) signature check is easily circumvented.
The next problem is that the disk assumes volume 255.
Either that needs to be worked around, or a NIB is preferable.
Cheers,
Nick.
Michael J. Mahon
Hopefully, it's not too hard to patch it to accept the default
volume number...(though it's also annoying that the .dsk/.do
format doesn't include a volume number or means for conveying it).
I wish that emulators would scan .dsk/.do filenames for the
presence of, say, ".v" followed by a volume number, followed by ".",
if such a substring is in the name. This would be a simple way
to provide the volume number associated with an image through
"out of band" signalling.
Unmodified emulators would, of course, pay no attention.
Requiring use of the much less appealing .nib format to convey a
single byte of information is a problem that should be addressed.
Charlie
"Michael J. Mahon" <mjm...@aol.com> wrote in message
news:j5idnV_WFZDwabvX...@giganews.com...
> Nick Westgate wrote:
>> On Jun 3, 2:34 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>>> The machine will "break" almost immediately, then you can examine
>>> the
>>> code (and data) in the region $8AFA..$8BFB and I can guarantee that
>>> you
>>> will see what it does to signature check the disk. (Of course, that
>>> means accessing the disk, so there things may get more technical.)
>>
>> Yes, this (!) signature check is easily circumvented.
>>
>> The next problem is that the disk assumes volume 255.
>> Either that needs to be worked around, or a NIB is preferable.
>
> Hopefully, it's not too hard to patch it to accept the default
> volume number...(though it's also annoying that the .dsk/.do
> format doesn't include a volume number or means for conveying it).
>
> I wish that emulators would scan .dsk/.do filenames for the
> presence of, say, ".v" followed by a volume number, followed by ".",
> if such a substring is in the name. This would be a simple way
> to provide the volume number associated with an image through
> "out of band" signalling.
>
> Unmodified emulators would, of course, pay no attention.
>
> Requiring use of the much less appealing .nib format to convey a
> single byte of information is a problem that should be addressed.
>
Why not have the emulator read the volume number from the VTOC, Track
$11, Sector $00, byte $06 on any normal .dsk/.do image? If emulators
already do that (and the original had a different volume number in the
track/sector address headers) then in this case all that should be done
is that one byte should be edited to 255.
Of course there were (I believe) disks that used different volume
numbers in the headers of different tracks/sectors but that could cause
problems with an image filename scheme as well.
Charlie
Poake
> "Michael J. Mahon" <mjma...@aol.com> wrote in messagenews:j5idnV_WFZDwabvX...@giganews.com...
This is something I've never understood. The volume number is right
there in the VTOC and ignored in the emulator. Having the ability to
inject a volume number via a setting into the emulator is another
option (overriding vtoc values) but it should at least read the .dsk
as it is formatted.
Nick Westgate
> as it is formatted.
Those are the key words right there.
Relying on a standard DOS layout is not possible.
Actually I implemented V in the filename for AppleIIGo recently, but
some other emulator authors could object that it looks pretty ugly and
might prefer that people use NIB or 2IMG for the few images that need
it.
Cheers,
Nick.
Michael J. Mahon
I submit that .NIB images are much "uglier" than a stylized
filename. ;-)
(But I also like the VTOC as a default if no "V" is specified.)
sirg...@optonline.net
sectors. Didn't Copy II Plus have a utility for changing volume numbers??
John.
Little Birdie In The Sky....
Nick Westgate
> Tried making a NIB. ADT's transfer wouldn't boot. SST+Ciderpress kept telling me the data didn't look right for DOS
> sectors. Didn't Copy II Plus have a utility for changing volume numbers??
>
> John.
You could try to use NIB2FILE in this case.
(That doesn't work well for most protected disks though).
Anyway, I will have a look at RSVP on the weekend.
Cheers,
Nick.
Nick Westgate
> 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
Toinet
Now that I am about to have some spare time thanks to the end of my
last big project, I will try to crack the program and comment it as I
generally do on http://www.hackzapple.com/phpBB2/viewforum.php?f=13
I understand from your message that 1/ there are end markers change
(B942:18 I presume) and 2/ there is a nibble count somewhere. As
written by Nick, other checks must be "checked"
antoine
sirg...@optonline.net
John.
Little Birdie In The Sky....
sirg...@optonline.net
Yes on the markers. Yes on the ddmover check. Will you need a true copy, of will the imsges be enough??
Cannot make a working copy, but you would have the protection.
John.
Andy McFadden
> > Those are the key words right there.
> > Relying on a standard DOS layout is not possible.
>
> filename. ;-)
FWIW, the 2IMG format allows you to specify a disk volume number. I don't
know how many emulators will use it though.
There's a 2IMG properties tool in CiderPress that can view/edit the value.
--
Send mail to fad...@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
sirg...@optonline.net
When the program starts up, you select a player name, or type in a new one, and press return.
ane wait, and wait, and wait, and wait...........
Think you or Antoine can find this one??
John.
Nick Westgate
> Thanks Nick for bypassing the DDmover check. I finally took time to check it out, and found a problem.
>
> When the program starts up, you select a player name, or type in a new one, and press return.
>
> ane wait, and wait, and wait, and wait...........
I tested it this much before sending you the image,
and it works fine for me.
You'll have to be more specific.
Cheers,
Nick.
sirg...@optonline.net
I boot the Program Disk, with the data side in drive 2.
It runs thru the 'Program Loading', RSVP Title screen.
It puts up the player list, asking me to choose a player.
Following instructions, I delete one of the existing names, and type in mine.
I hit return, and nothing else happens. The program just seems to stop.
If it works for you past this point, maybe the copy I got from you got hit by Gremlins??
FWIW, I'm using Applewin 1.13.0.0
John.
Little Birdie In The Sky....
Poake
> Sure thing, Nick. I have it in the emulator now.
>
> I boot the Program Disk, with the data side in drive 2.
>
> It runs thru the 'Program Loading', RSVP Title screen.
>
> It puts up the player list, asking me to choose a player.
>
> Following instructions, I delete one of the existing names, and type in mine.
>
> I hit return, and nothing else happens. The program just seems to stop.
>
> If it works for you past this point, maybe the copy I got from you got hit by Gremlins??
>
> FWIW, I'm using Applewin 1.13.0.0
>
> John.
>
> >On Jun 14, 11:30 pm, sirgh...@optonline.net wrote:
> >> Thanks Nick for bypassing the DDmover check. I finally took time to check it out, and found a problem.
>
> >> When the program starts up, you select a player name, or type in a new one, and press return.
>
> >> ane wait, and wait, and wait, and wait...........
>
> >I tested it this much before sending you the image,
> >and it works fine for me.
>
> >You'll have to be more specific.
>
> >Cheers,
> >Nick.
>
> 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!!
Change Applewin to use Apple //e mode. ][+ rom mode doesn't work.
Toinet
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
sirg...@optonline.net
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.
Little Birdie In The Sky....
Michael
protection routines! I never did figure out how to backup my Wings of
Fury disk.
Cool Thread too :-)
Michael
AppleWin Debugger Dev
Toinet
You are welcome Michael, thank you for your message.
Wings of Fury from Broderbund is a two sided disk with a nice 18-
sector protection. EDD may be the only capable software to back it up
but I am not sure as WoF contains the following list of protections:
- 18-sec protection
- desynchronization (find hidden nibbles on track 0, use them to
decypher some code)
- use of the stack to lose the mean pirate
I like that one ;-) I used WoF routines to create an disk image of the
game but it is not usable, it is just a RAW image which needs to be
converted to 16-sec, one day...
Antoine
lyricalnanoha
> On 4 juil, 18:26, Michael <michael.pohore...@gmail.com> wrote:
>> Thx for the link Antoine -- _lots_ of fun reading those old copy
>> protection routines! Â I never did figure out how to backup my Wings of
>> Fury disk.
>>
>> Cool Thread too :-)
>>
>> Michael
>> AppleWin Debugger Dev
>
> You are welcome Michael, thank you for your message.
>
> Wings of Fury from Broderbund is a two sided disk with a nice 18-
> sector protection. EDD may be the only capable software to back it up
> but I am not sure as WoF contains the following list of protections:
> - 18-sec protection
> - desynchronization (find hidden nibbles on track 0, use them to
> decypher some code)
> - use of the stack to lose the mean pirate
>
> I like that one ;-) I used WoF routines to create an disk image of the
> game but it is not usable, it is just a RAW image which needs to be
> converted to 16-sec, one day...
>
> Antoine
>
18 sectors, eh?
That got me to thinking. That's the same track length as an MS-DOS 2.x
floppy disk... I wonder if it's possible to create a hack of DOS 3.3 that
uses 16-sector track 0 and 18-sector tracks 1-34, and how reliably it
could be used as a read/write OS. (Or even to add an additional track
though I don't think any emus support that, even on nib?)
-uso.
Michael J. Mahon
> On Sat, 4 Jul 2009, Toinet wrote:
>
>> On 4 juil, 18:26, Michael <michael.pohore...@gmail.com> wrote:
>>> Thx for the link Antoine -- _lots_ of fun reading those old copy
>>> Fury disk.
>>>
>>> Cool Thread too :-)
>>>
>>> Michael
>>> AppleWin Debugger Dev
>>
>> You are welcome Michael, thank you for your message.
>>
>> Wings of Fury from Broderbund is a two sided disk with a nice 18-
>> sector protection. EDD may be the only capable software to back it up
>> but I am not sure as WoF contains the following list of protections:
>> - 18-sec protection
>> - desynchronization (find hidden nibbles on track 0, use them to
>> decypher some code)
>> - use of the stack to lose the mean pirate
>>
>> I like that one ;-) I used WoF routines to create an disk image of the
>> game but it is not usable, it is just a RAW image which needs to be
>> converted to 16-sec, one day...
>>
>> Antoine
>>
>
> 18 sectors, eh?
>
> That got me to thinking. That's the same track length as an MS-DOS 2.x
> floppy disk... I wonder if it's possible to create a hack of DOS 3.3
> that uses 16-sector track 0 and 18-sector tracks 1-34, and how reliably
> it could be used as a read/write OS. (Or even to add an additional
> track though I don't think any emus support that, even on nib?)
An 18 sector track is obtained by deleting the self-sync "gaps" that
allow for writing, so it is a read-only track.
-michael
NadaNet 3.0 for Apple II parallel computing!