Roller ball copy protection.

Enlighted (6034)

07-07-2017, 21:12

Manuel wrote:

Apparently people fixed that in the cracked disk/tape version....?

I took a look of the cracked disk version and it seems the solution there is not very elegant :) The tables are patched to fix the problem just before the tables are used and then the tables are broken again to prevent this fixed version to be caught by the next check that obviously they failed to find as well. (I haven't found the routine yet either) With graphics the trick is similar. It keeps a backup of working graphics and restores the backup just before graphics are needed. Obviously this cracked version could not fit back in to original 16K ROM chip. :)

By Louthrax

Prophet (2439)

07-07-2017, 23:01

I'd still go for the "duct tape" solution (replacing "poke" corrupting the ROM with calls to a function that chech address validity). Repeat the fixing process until no more pokes in ROM are detected by openMSX. Extra-code should not be too big? And sorry for polluating the Tales of Popolon thread

Extra note: Quarth from Konami also had a bug (I don't think this was a copy protection) like that. Launch the game in RAM with your favorite MegaROM launcher, loose a game, and note that the numbers for the "continue" countdown have corrupted GFX. I made a fix for that in the early 90's, lost it, did another one again 2 years ago... and lost it again (darn!).

By NYYRIKKI

Enlighted (6034)

08-07-2017, 01:57

You can't duct tape every 1 or 2 byte instruction with 3-byte call. Especially not in this kind of code where everything is put in to tables... even the pointers them self. It will become just a huge & slow mess. This method will also fail on the internal checksum check and has no possibility to stay inside 16KB as there are just dozen or so free bytes in the ROM.

When I found all the related routines taking down the whole copy protection mechanism was possible with 3-byte patch after some careful planning. There is still this graphics corruption problem (that I've actually duct taped) that is a real bug... When the paddles are updated to screen it will mess up the pointer of next graphical update buffer so that previous LDIR source address becomes new target or something close to that. When the code is in ROM the only problem is that some item in screen does not get a proper update and stays on previous frame state, but when it is in RAM the paddle graphics get messed up... This may not be totally accurate description, but pretty close. The whole "moving tables pointed by pointers of pointers of pointers"-engine is such a galactic size mess that I really don't seem to figure out heads or tails of what is supposed to be where and when.

By gdx

Enlighted (6122)

08-07-2017, 03:07

Try to replace the following bytes:

000004h: 00 00 00 -> C2 07 91
000009h: 00 00 00 00 -> 32 A4 CC C9
00115Ch: 20 A9 C9 -> C3 04 80
0019B7h: 28 -> 18
0025B4h: FE -> 28
0025E1h: 18 -> 20

By Louthrax

Prophet (2439)

08-07-2017, 02:52

So that looks like a hellish protection mechanism here, if that's really protection mechanism and not only bugs? I do not think other HAL games like Eggerland have copy protection?

I used that "duct tape" approach to slowdown FM-PAC code on turboR for some disk games, and that was indeed a mess, requiring adding individual extra functions for each "out (FMPACPORT),a" depending on the subsequent instruction, with push/pop sequences to preserve registers used in the delay routine... Of course timing was not critical here as the point was to delay the game, and I had enough room on disk to add those new routines.

By NYYRIKKI

Enlighted (6034)

08-07-2017, 03:15

gdx wrote:

Try to replace the following bytes:

000009h: 00 00 00 00 00 00 00 -> C2 07 91 32 A4 CC C9
00115Ch: 20 A9 C9 -> C3 0A 80

Before you edited the post you got the crack correct

Ok, let me correct:
0009h: 00 00 00 00 00 00 00 -> C2 07 91 32 A4 CC C9
115Ch: 20 A9 C9 -> C3 09 80
19B7h: 28 -> 18
25B4h: FE -> 28
25E1h: 18 -> 20

The crack is same that I came up with, but this graphics workaround is much better than what I came up with! I think we are very close to real solution now! This makes the corruption to go to address 04B0h ->

I didn't pinpoint that word on CCA3h... Now I think we just need to update it on correct place in order to fix this once and for all... but first some sleep now.

By gdx

Enlighted (6122)

08-07-2017, 03:29

I tried to simplify it quickly but it was not good. So I re-edited my message with the original patch. Look it again now I think it's okay.

By NYYRIKKI

Enlighted (6034)

08-07-2017, 12:32

Ok, now I think we are done.

Here is a patch that actually points the graphical data to buffer where it is supposed to go instead of some random "less hazardous" address:

8004: 00 00 00 00 00 00 00 00 00 00 -> C2 07 91 01 52 CD ED 43 A3 CC C9
115C: 20 A9 C9 -> C3 04 80
19B7: 28 -> 18
25B4: FE -> 28
25E1: 18 -> 20

Puzzle solved

By Manuel

Ascended (19330)

08-07-2017, 12:57

So, there is a bug... but is there also still a copy protection scheme you talked about? I'm a bit confused now. Can you give an overview?

By NYYRIKKI

Enlighted (6034)

08-07-2017, 14:00

Manuel wrote:

So, there is a bug... but is there also still a copy protection scheme you talked about? I'm a bit confused now. Can you give an overview?

Sure:

8004: C2 07 91 01 52 CD ED 43 A3 CC C9 ; Patch to move the graphics buffer address to correct place instead of address in ROM memory space.
115C: C3 04 80 ; Entry point for the patch
25B4: FE -> 28 ; 1st level protection -> patch code breaking byte to same value as in code already
25E1: 18 -> 20 ; 1st level protection -> patch code breaking byte to same value as in code already
19B7: 28 -> 18 ; 2nd level protection -> Accept any checksum value

If you fail 1st level protection, you can't start a game. You can only look demo.
If you fail 2nd level protection, you can start a game, but it will always run in demo mode.

By tfh

Prophet (3321)

08-07-2017, 15:08

Any chance of releasing the correctly patched .ROM file?