Make DSK image from protected floppy

Pagina 9/16
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | 13 | 14

Van Manuel

Ascended (17511)

afbeelding van Manuel

01-07-2012, 22:42

wernerkai: as I wrote in the instructions: you will need several disks in drive B: to get all files. Or swap them after copying the files to your PC (or some other place). Ah, you realized that also in your 2nd post Smile

Van Manuel

Ascended (17511)

afbeelding van Manuel

02-07-2012, 10:00

Well, wernerkai got his first dump with the HB-3600 Smile

Van ~mk~

Champion (275)

afbeelding van ~mk~

11-07-2012, 23:32

Hello saccopharynx excellent article on copy protections, very educational even for those of us without knowledge on cracking. Thanks a lot for documenting and sharing your discoveries.

However, if I understood correctly, you focus on hacking the DSK files so that the loader thinks the disk has the original format. Do you think it would be possible to hack the the loader (the program itself) so that the format check subroutine is skipped and the games load on standard disks?

I have some disks with the copy protections you mention in the article and I'm looking into making it work on disks with standard format.

PD: De que parte de Argentina sos? Sabias que todos los años se vienen haciendo reuniones de usuarios de MSX en Buenos Aires? Seria buenisimo contar con tu presencia en alguna reunion! Tambien si queres participar de la lista de correo, este es el mail: RetroMSX@gruposyahoo.com.ar. Saludos!!! :RNFF:

Van saccopharynx

Master (151)

afbeelding van saccopharynx

12-07-2012, 04:07

Hi ~mk~,

Thanks for your comments. The tutorial basically describes non-standard formats given to floppy disks. Then, as a part of the whole protection (remember that games are additionally encrypted), there was a subroutine that checked the format of the diskette and if it was not as expected, the system used to be halted (intentionally, of course).

As this particular copy-protection system cannot be totally emulated in DSK images, some modifications are required. So, what I did was to modify the protection in order to verify the existence of, for example, CHS=(0,0,#ff01) instead of (0,0,2). It's worth mentioning that a copy-protected disk had not any sector numbered as #2 in the first track (cyl = 0 / head = 0), so if sector CHS = (0,0,2) was detected, the disk was identified as a copy. Since reading sector CHS = (0,0,2) is always positive on emulators, the control subroutine cannot be passed without tricks, so some changes are necessary. The simplest one is to modify the subroutine so as to read the sector number #FF01, which is totally out of a valid range even though you work with DSK images of 3.5” disks. As a consequence, that sector is never found and the loader is executed normally.

Skipping the check subroutine could be more difficult, depending on the protection. Take into account that in order to by pass the protection with my method you only need to patch ONLY ONE BYTE. Removing the control may require several modifications as there might be several CRC controls and encryption loops.

Anyway, I've been trying the upcoming DMK format, which will be supported in further versions of openMSX, and all these protection systems can be perfectly emulated WITHOUT PATCHING ROUTINES, so that's the good news. Actually, I converted all my protected disks to that format and everything works just fine.

Regarding the meetings in Bs.As., I cannot attend since I don't live there anymore. I'll contact you by e-mail.

S.

Van ~mk~

Champion (275)

afbeelding van ~mk~

13-07-2012, 01:00

Thanks for the detailed explanation saccopharynx.
So, hacking the loader could be more difficult, that's bad news (or not, if you look at it as a challenge hehe).
I am interested in this instead of hacking DSK files because I want to play the games on a real MSX, with an IDE interface instead of a floppy drive, and most of the games I have are protected.
By the way check your e-mail Wink

Van Manuel

Ascended (17511)

afbeelding van Manuel

13-07-2012, 09:43

Well, I've been talking to the author of RUNit, and he said he is interested in supporting the DMK format. That means you could run protected dumps of original disks on your real MSX harddisk Smile

Van wernerkai

Champion (357)

afbeelding van wernerkai

15-07-2012, 22:24

I've noticed this week only that ImageDisk was updated in March/2012 to version 1.18

http://www.classiccmp.org/dunfield/img/index.htm

In the ZIP there is DMK2IMD.COM, present since version 1.16:

DMK2IMD.COM - DMK to ImageDisk conversion utility

Regards,

Werner

Van Manuel

Ascended (17511)

afbeelding van Manuel

17-07-2012, 22:27

~mk~ wrote:

Oh I was hoping it would work on every MSX Sad
Mine is a Talent TPC-310 with an external DPF-550 drive.

If you connect 2 drives, it could work with the National type parameter! Can you test that?

Van ~mk~

Champion (275)

afbeelding van ~mk~

21-07-2012, 19:35

Manuel wrote:

If you connect 2 drives, it could work with the National type parameter! Can you test that?

Not anytime soon because my MSX is having video output problems, and I only have one drive, but I'll test it as soon as my MSX works again and I can get hold of another drive. Thanks a lot Manuel.

Van Manuel

Ascended (17511)

afbeelding van Manuel

21-07-2012, 20:56

Now that we're talking about a Talent TPC-310.... I have a question to all owners of the machine Smile

We've been working on implementing this machine in openMSX. So far everything was working fine, except that in the accessories software, the cursor could not be moved, until a reset was done.

This all has to do with the initial values of the S1985 (or actually YM3814 in this case) back-up RAM. It would be very helpful if you could help us out by executing this small basic program and tell me what it prints:

10 OUT 64,254
20 FOR AD=0 TO 15:
30  OUT 65,AD
40  PRINT INP(66);:PRINT " ";
50 NEXT

This would help a lot!

Details for those interested (skip if you're not interested):

We found the root cause of the issue: it's not the initialization of the normal RAM, but the backup RAM of the S1985 (or YM3814 in this case). It has 16 bytes of RAM. And the accessories software uses the first byte to persist mouse or cursor use. When the first byte is 0xFF, it assumes nothing, but writes 0 afterwards (being cursor use). Next time, it will use the cursors normally.

In openMSX, the persistency of this back-up RAM was not implemented. It is implemented now. This means that the issue only occurs once, for the first time. After that, the 0 is written and it's remembered for next time and thus it works next time.

The question is of course: how is the back-up RAM initialized? If it's initialized with zeroes, the problem will never occur. If it's initialized with 0xFF, it will occur exactly once... On a Sony HB-F700D which I tried, most values were 255, which suggest initialization on 0xFF, which also means a small (occur-once) bug on the accessories software. But maybe it's different for the YM3814 version of this chip...

Pagina 9/16
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | 13 | 14