Rayman DOS versions - no-CD patches

[dr_st]

After beating Mr. Dark, every time you re-enter any level, you get greeted with the Atari Jaguar intro image, displaying the level number (relative to the world) of that level. For example, Allegro Presto will display "Level 7", Mr. Skops Stalactites - "Level 9" and Mr. Dark's Dare - "Level 1". Then the game proceeds as always. See attached image. Is this documented anywhere?

That is the level select the developers used to test the levels in the game. It's available in the code of essentially all versions but is only functional and accessible in the PC version. It's accessed by pressing the tab key, typing "alevel" and then pressing backspace. Not sure why it appeared in this case, but from my understanding the game's code was modified? It won't appear normally without inputting the cheat code.

No, it works on unmodified 1.21. However, you have just added the last piece of the puzzle, thank you!

Indeed this is the sub-level select feature that is available through the [TAB]aleve[BACKSPACE] cheat. So I suppose this was an intentional developer choice in 1.21 - once the game is beaten - give the player the ability to replay any sublevel at will.

Left and right arrow keys select the level number, and you can even replay Boss and Betilla levels this way! As far as I know, this is the only way these levels can be replayed (without hacking) in any Rayman version.

Sadly, Mr. Dark's Dare cannot be replayed. With the help of the cheat, you can start on any sublevel the first time through, but once you beat sublevel 4 (the boss battle), you cannot replay any of the levels again. Selecting Level 1 takes you to the endgame vignette + credits, and selecting Levels 2-4 does the same, except it shows the ending movie first.

I will soon update the wiki with accurate information, now that we've reached what seems a full understanding of this feature.

[RayCarrot]

After beating Mr. Dark, every time you re-enter any level, you get greeted with the Atari Jaguar intro image, displaying the level number (relative to the world) of that level. For example, Allegro Presto will display "Level 7", Mr. Skops Stalactites - "Level 9" and Mr. Dark's Dare - "Level 1". Then the game proceeds as always. See attached image. Is this documented anywhere?

That is the level select the developers used to test the levels in the game. It's available in the code of essentially all versions but is only functional and accessible in the PC version. It's accessed by pressing the tab key, typing "alevel" and then pressing backspace. Not sure why it appeared in this case, but from my understanding the game's code was modified? It won't appear normally without inputting the cheat code.

No, it works on unmodified 1.21.

I'm confused by what you mean here. The level select does not trigger after beating Mr. Dark on any 1.21 copy that I've seen. Which game copy are you using?
I also checked the decompiled code for my 1.21 copy and that screen is only ever triggered from the cheat. It gets triggered when the ALL_WORLD flag is true (which is only ever set to true when the cheat code is entered) and get_casse_brique_active is false (which makes sure you're not entering the breakout minigame).

Edit: Btw if you want to replay the final level you can do it by editing the save in RCP (export to json, edit the boss flags and then import again). The boss flags has a bit for every boss you've beaten (as well as story events like helping Joe, the Musician etc.). I should probably make a nicer ui for this though so it's easier to find.

[dr_st]

OK, the plot thickens.

Following your post, I went and rechecked everything, and I now believe that we are seeing some unintentional effects of cross-version save compatibility.

My original saves are from EU version 1.12. These saves load correctly in 1.21, and it seems that if you take a post-Mr. Dark save that was created in 1.12 and load it in 1.21, this enables the level select screen.

I had previously thought that I could trigger the behavior by taking a pre-Candy Chateau save in 1.21, and beating the game, but I tried reproducing it today and it did not work - the level select screen was not triggered. This is consistent with your findings. I must have been confused with all the experiments I had been running at that time.

You can examine it with the saved games in the ZIP I attached. RAYMAN2.SAV (95 lives) was created in 1.21 and does not trigger the level select screen. RAYMAN3.SAV (97 lives) was created in 1.12 and triggers the level select screen in 1.21.

P.S. The effect never happens in 1.12 (whether you load a save from 1.12 or from 1.21).
P.P.S. You have exactly 7,000 tings more than I do!

[Hunchman801]

Now that's an interesting side effect! From what I've seen of Rayman Control Panel, I assume that we have a good understanding of the structure of Rayman 1 save files, so hopefully we can isolate the component responsible for this.

P.P.S. You have exactly 7,000 tings more than I do!

I have a feeling you'll catch up.

[RayCarrot]

Oh wow, this was quite unexpected. Indeed your save triggers the level selection, but this is due to a developer oversight! I'll try to explain it best I can. Here is a part of the function which reads the save file:

Code: Select all

    SaveFileRead((int)savFile, &bonus_perfect, 0x18u);
    SaveFileRead((int)savFile, &world_index, 2u);
    SaveFileRead((int)savFile, finBosslevel, 2u);
    SaveFileClose((int)savFile);

The third argument determines the size of the value in bytes. So "world_index" (which determines on which world map icon you're on) is stored as a 16-bit value in the save file. Now if you look at the actual data in the game memory then "world_index" is a single byte, an 8-bit value. This means that when the game reads or writes the save it's actually keeping an additional byte!
Now usually this won't be an issue if you're on the same version of the game - each time the game will read/write the save then whatever that additional byte is will always be the same. But here we have an interesting case - in version 1.21 in memory the byte right after "world_index" is "ALL_WORLD", the flag which checks if you've entered the level select cheat! The game will think the level select is triggered as long as "ALL_WORLD" is not 0. So if when the save gets written to and the byte right after "world_index" is a non-0 value and that save is then used in version 1.21 then the game will think you've entered the cheat. A complete oversight on the developers end haha. Ideally the save reading/writing would only keep a single byte, or they would reserve the byte after "world_index" in memory for padding.
To verify this I checked your third save and indeed the "world_index" value is 0x6611 (much larger than an 8-bit value :p). Taking the first byte we get the actual value, which is 17, but then we have some data set in the second byte which then causes "ALL_WORLD" to be set in 1.21. Each version has the data structured differently in memory, so the version you got the save from must have a different value after "world_index".

[dr_st]

Thank you for looking into it. So in the end we have here a #YetAnotherBufferOverflow.

[Hunchman801]

Thanks for the in-depth explanation, I'm so glad we don't have to manipulate pointers like this nowadays.

[cps2x]

Hello

I recently discovered these nocd patches and I tried to replicate with the version "Rayman (EU) v1.12".

The decompression and patching went well, but once I run the game, after the ubisoft logo and rayman animation, it freezes and does not reach the menu.
With the original executable, it works without problem.

I did the following tests.

- Uncompress the executable with pmwunlic.exe and pmwunlit.exe.

Tests on two different systems.

- Linux Dosbox 0.74-2

- Windows 10 Dosbox 0.74-3

I don't know what could be going on, it's strange.

I would like to congratulate you for the work, the texts written about the crack were very interesting.

Thanks

[dr_st]

Let's try to see what's going on.

Could you share the following information?

• Rayman.exe compressed size
• Rayman.exe decompressed size
• Binary differences (e.g., output from FC between the files) of the original and patched version

(to be sure that we are dealing with the same version and that the patching was accurate)

Also to clarify: you installed the game normally from the CD, and then applied the crack? Does the original (compressed, unpatched) executable run well on your system, with the CD in drive? Does the patched version run with the CD in drive?

[cps2x]

Ok, I think it's correct, but it's not too much to check it.

Rayman.exe compressed size: 425.468 bytes (MD5: 9f2fb7fec4e4982de3abf6597bf9ca41)

Rayman.exe decompressed size: 928.110 bytes

ORIGINAL VS. PATCHED
0008E968: 75 EB
0008E997: 75 B0
0008E998: 0F 00
0008EA58: 01 00
0008EA6B: 0F 90
0008EA6C: 84 90
0008EA6D: 71 90
0008EA6E: 01 90
0008EA6F: 00 90
0008EA70: 00 90
0008EA79: 75 EB
0008EA93: 25 E9
0008EA94: FF A5
0008EA95: 00 01
0008ED5C: 53 C3
0008F10E: 74 EB


you installed the game normally from the CD, and then applied the crack?

Yes.


Does the original (compressed, unpatched) executable run well on your system, with the CD in drive?

Yes.


Does the patched version run with the CD in drive?

If it works, with or without CD it does the same thing, ubisoft logo, rayman animation and then it freezes.


thanks in advance

[dr_st]

So far it seems identical to my patch and the MD5 matches my RAYMAN.EXE.

What about the decompressed, but unpatched version? Does that work fine with the CD in drive, or does it also freeze?

I wonder if there may be other ways in which decompression can corrupt the program, that I haven't encountered.

Feel free zipping up your uncompressed EXE and attaching it to a forum post, and I can take a look offline.

[cps2x]

What about the decompressed, but unpatched version? Does that work fine with the CD in drive, or does it also freeze?

Unfortunately it does not work either, same result.


I include 3 executables.

- Uncompressed with PMWUNLIT, patched and unpatched.
- Uncompressed with pmwunlic unpatched, differs in a few bytes with the pmwunlit version, it does not work either.

I am using dosbox to uncompress, as you said, it seems that it could be a problem of decompression.

[dr_st]

I realized that I should have asked you - does the decompressed version run after you change only the offset at 0x8F10E (obviously, it would not run without this change).

In any case, your RAYMAN_uncompressed_with_PMWUNLIT_and_patched.EXE - works for me in DOSBox 0.74, 0.74-3 and SVN. With or without the CD.

I would have thought you have an unrelated configuration issue, but since the original EXE works for you, I don't quite understand what's going on. Very weird.

[cps2x]

I realized that my original CD is version 1.20, I downloaded v1.12 from redump thinking it was my version.

In any case, patching only 0x8F10E in v1.12 doesn't work either, actually with or without patch it does the same, ubisoft logo, rayman animation, frozen.

It strikes me that I get to start the game, see the ubisoft logo ... and in your case it exits before without the 0x8F10E patch.


Then I tried with version 1.20, and I had the same result, in this case without patching, but I get to the same point (with the original EXE works).

These last tests have been from a windows 7 with dosbox 74 and 74.3, the dosbox configuration is the one that comes by default when installing.


Finally I tested the US version 1.21 and it worked correctly, only decompression without patch, but I got to the menu.


I don't see any logic, unless for some reason the executables are decompressed wrong, but in that case they shouldn't work either.



It's all very confusing

[cps2x]

Well, I think I have solved the mystery.

It turns out that the European versions must have RAYMAN.EXE check, apparently it is crc check, since changing a single byte fails.

If I put the patched EXE with another name than RAYMAN.EXE and I keep the original RAYMAN.EXE, I can run without problem and of course it is necessary to patch the offset 0x8F10E.

In v1.20 EU the exact same thing happens, I had to patch the "decompression bug" at 0x9066E.


Thanks to the user RibShark, who mentioned exactly the problem I had in another forum, he is also a user of this forum, he says he has it patched.

https://www.tapatalk.com/groups/tehrune ... t1574.html

[dr_st]

Wow, what a bizarre situation. That explains why I never encountered it - I kept my original (compressed) EXEs and had the modified files at different names.

I will go back at some point and test all versions with the original names, to see which ones are affected. Hopefully, it won't be hard to find the function which must be skipped (RibShark left no details on where in the file it is exactly).

True that this is not a mandatory patch, since there is a workaround, but for the sake of completeness, I'd like to tackle it.

Also, could you share your 1.20 EU executable and the patch offsets you've discovered there so far? I will add it to the article as well.

Thank you for participating in the research.

[RayCarrot]

You might be able to modify the checksum value itself as well. It's stored several times in the allfix file. It appears to exist two variants within each DES entry (the graphics) and then a third one after those. It also seems to store the size of the exe. Not sure which ones of these are used and how they work, but you can probably check that in the "LOAD_ALL_FIX" function where it parses each value.

Edit: I had a quick look in version 1.21 and it seems these values might be unused... Maybe they're only used in older versions of the game?

[dr_st]

Yeah, 1.21 does not validate RAYMAN.EXE (or care that it even exists).

In the end it was quite easy to remove this extra check in 1.12 EU, because it is called straight from main(), so I didn't have to go too deeply into the code. The offset to change is 0x8EF2C: 53 → C3.

cps2x, if you share your 1.20 EU, I can take a look at that as well.

[cps2x]

Wow, what a bizarre situation. That explains why I never encountered it - I kept my original (compressed) EXEs and had the modified files at different names.

I will go back at some point and test all versions with the original names, to see which ones are affected. Hopefully, it won't be hard to find the function which must be skipped (RibShark left no details on where in the file it is exactly).

True that this is not a mandatory patch, since there is a workaround, but for the sake of completeness, I'd like to tackle it.

Also, could you share your 1.20 EU executable and the patch offsets you've discovered there so far? I will add it to the article as well.

Thank you for participating in the research.

Starting from EU v1.12, I have added 0x1560 to each offset

Code: Select all

0008FEC8: EB 75
0008FEF7: B0 75
0008FEF8: 00 0F
0008FFB8: 00 01
0008FFCB: 90 0F
0008FFCC: 90 84
0008FFCD: 90 71
0008FFCE: 90 01
0008FFCF: 90 00
0008FFD0: 90 00
0008FFD9: EB 75
0008FFF3: E9 25
0008FFF4: A5 FF
0008FFF5: 01 00
000902BC: C3 53
0009066E: EB 74

Investigating a little more about the "decompression bug", it seems to be one more layer of protection, if we change the name of the original compressed exe, it also comes out to msdos.

Looking a little bit at the disassembly, in the code before the patched jump, it does some string handling, I guess it checks the name.

Glad to participate, it is being very interesting.

Rayman (EU) v1.20.7z

(396.04 KiB) Downloaded 174 times

You might be able to modify the checksum value itself as well. It's stored several times in the allfix file. It appears to exist two variants within each DES entry (the graphics) and then a third one after those. It also seems to store the size of the exe. Not sure which ones of these are used and how they work, but you can probably check that in the "LOAD_ALL_FIX" function where it parses each value.

Edit: I had a quick look in version 1.21 and it seems these values might be unused... Maybe they're only used in older versions of the game?

BinaryDataExplorer_0.1.0.0_2021-09-12_09-40-45.png

I tried to calculate the crc of my file but it didn't match, I don't know what algorithm they used, I would have to investigate the code to see it, anyway I was able to discover the tools you have in your github.

Thanks for your help!

[dr_st]

Investigating a little more about the "decompression bug", it seems to be one more layer of protection, if we change the name of the original compressed exe, it also comes out to msdos.

Indeed. And now another mystery is solved. This makes a lot more sense than there being a random decompression artifact only in this version.

It is indeed crazy how paranoid they were here.

1. First the program checks its name and aborts if it is not as expected.
2. Then it does the standard CD checks.
3. Then it looks for the file with the original name (never mind the name of the program being run at this point) and validate its integrity.
4. And if you bypassed all that - it tests the video files on the disc when you try to play advanced levels.

Funnily - if I had kept the name of the file I worked on as RAYMAN.EXE, I would have never triggered issue (1), but I would have discovered issue (3) that I missed.

The lesson to learn from this - when patching programs test how they behave both with the original and with a different name.

Thank you for working on this. It is late and I am a bit tired now. Hopefully within the next few days I will get around to updating the article with all the amendments and corrections, and I will add your findings about EU version 1.20 to the table as well.