Rayman DOS versions - no-CD patches

[dr_st]

I'm reattaching the 1.20 which I've expanded with PMWUNLIT and patched according to my original addresses for EU 1.12 + the 0x1560 offset according to your instructions.

I expect it is correct, because the opcodes at the shifted addresses seemed to match exactly. I cannot really run the game, presumably because the data files for 1.12 and 1.20 are different. For sure it defeats the filename check and the basic CD checks during startup. IT proceeds up to the Ubisoft logo and the Rayman intro, but errors out before the menu with file integrity fault in RAY.LNG.

[PluMGMK]

Fairly long post incoming… God bless Georg Dahn…

So, RayCarrot was kind enough to provide me with install directories of all the versions he had collected, and I spent a few days plumbing support for them into the TSR. In the course of this work, I have come to the conclusion that the earliest and rarest versions, v1.00 and v1.10, are EVIL!

Both of them have way more DRM than the subsequent versions. Firstly, there are additional checks on the CD at initialization. That's fair enough since, at least they're upfront. It makes sure that the "copyright", "abstract", and "bibliographic doc" filenames are all "RAYMAN", which makes sense. It then checks that the CD has exactly one data track, and exactly 25 audio tracks, and exactly the right total number of sectors (obviously different between the two versions). I am somewhat bemused by the fact that they knew the right number of sectors when they were still writing the code – I guess they compiled it with a dummy number, calculated the number of sectors and then wrote that back into the code and recompiled.

Next come the sneakier checks, which happen while the game is running. As per the newer versions, on loading a map with num_world>=2 and num_level>=7, the game checks the file-sizes of INTRO.DAT and CONCLU.DAT on the CD, and crashes without warning if they are not as expected. But in these early versions, there's more… There are three points in the code where the game checks if the CD's volume label is also "RAYMAN". It checks this at initialization, when loading the world map, and when loading a level. If the volume label is wrong, the game goes into Limited Mode without warning, even if the check fails at initialization! (Note that the other initialization-time checks put up a message giving you a choice between changing the disc, playing in Limited Mode, or exiting.) When the game is in Limited Mode, it crashes after finishing a level.

There are a couple of other interesting points about this volume label check. Firstly, the code looks as if it's going to check for the label "RAYMANVOL", but then at the last moment replaces the 'V' with a null byte, truncating the string to "RAYMAN". I guess they were planning on using a longer volume label at some point – God knows why, or why it changed… Secondly, all the newer versions also check the volume label, but they don't act on the result. This is presumably because later versions can be included in bundles, so the volume label can legitimately be "RAYGOLD", or "RAYFAN", etc.

Now so far, all this seems fairly reasonable. But this next bit is truly shocking…

Each WLD file contains two bytes near the beginning known as BiosCheckSum and VideoBiosCheckSum. In most versions of the game, they are unused. But in v1.00 and v1.10, they do exactly what they say on the tin. When the game finishes loading a WLD file, it checks whether or not it is running from the CD. If it is, everything is fine, but if the game is running from your hard drive (which it surely is if you've installed it…), it proceeds to calculate the checksum of your BIOS ROM (i.e. memory in the address range 0xF0000–0x100000). If it doesn't match what's in the WLD file, then the game goes into Limited Mode without warning.

Just think about that for a second. If your BIOS doesn't match the one used by the developers, the game will not work properly.

Then, when loading a level, it calculates the checksum of the graphics card ROM (assumed to be in the address range 0xC0000-0xD0000). Again, if this doesn't match the VideoBiosCheckSum, the game goes into Limited Mode without warning. Essentially, those two checks mean: if you want to run the game from the hard drive, you have to have the same motherboard and graphics card as the game's developers!

It gets even worse though. When you're saving the game, it first does that same check on the BiosCheckSum, and if it fails, it hangs the machine! Then it creates/updates the save file, then it checks the VideoBiosCheckSum. Again, if it fails, it hangs the bloody machine! Now, again, these checks are only done if the game is running from the hard drive, but still, that's pretty awful. Now I see why these versions are so rare, since they must have been basically broken for a large chunk of the user-base…

Apart from that, there's another interesting thing I noticed about these two versions. Version 1.00 is the only one that doesn't check if it's running on OS/2 (as opposed to real DOS) on startup. Version 1.10, on the other hand, skips all the CD checks (including the extra ones mentioned here) if it detects that it's running on OS/2. I don't think there are any other Rayman versions that skip the checks specifically if running on OS/2, although the newer versions do skip the bit that hangs Dosbox (since it presumably would hang the OS/2 DOS box too):

As I recall, the game keeps polling the drive until it reports its status as fully open, or something like that, which I guess never happens in Dosbox…

However, even if running on OS/2, v1.10 still carries out those evil BIOS checksum checks if it's running from the hard drive. I'm not too familiar with OS/2's DOS box, but it seems unlikely to me that it would even allow access to the real hardware ROM, so those checks must be pretty much guaranteed to fail in that case…

––––––––––––––––
On a separate note:

I'm gonna have to look into that #GP with the Intro/Conclu files – it sounds intriguing!

What happens is this. A routine calls an inner routine. The inner routine is identical in both versions (US 1.21 and FR 1.21). The calling routine is different and the one in US 1.21 is corrupt and does not set up the registers properly before the call. Unfortunately, the bad routine is also 15 bytes shorter, so there is no way to simply replace the opcodes to make it do what it has to.

So, some good news: I've managed to figure out how this probably happened, and reproduce it with a minimal example. Here is CRASHPMW.C, a short program I wrote to demonstrate the issue:

Code: Select all

#include <io.h>
#include <share.h>
#include <stdio.h>
#include <fcntl.h>
#ifndef CRASH
#include <dos.h>
#endif

#define BYTES_TO_READ 20
#define FILE_TO_OPEN "C:\\AUTOEXEC.BAT"

int main() {
	char bytes[BYTES_TO_READ+1];
	short hdl;
	unsigned int bytes_read;

	hdl = sopen(FILE_TO_OPEN, O_RDWR, SH_DENYNO);
	if (hdl < 0) {
		perror(FILE_TO_OPEN);
		return 1;
	}

	_dos_read(hdl, bytes, BYTES_TO_READ, &bytes_read);

	bytes[bytes_read] = 0;

	printf("Read the following %u bytes from %s:\n%s",
			bytes_read,
			FILE_TO_OPEN,
			bytes);

	return 0;
}

Thanks to the #ifndef, you can use the Open Watcom distribution to compile a working version like so:

Code: Select all

wcl386 -3r crashpmw.c
pmwlite crashpmw.exe

Or to compile a version that crashes with a General Protection fault, like so:

Code: Select all

wcl386 -3r -DCRASH crashpmw.c
pmwlite crashpmw.exe

Here's the corresponding disassembly listing (from IDA) for the working version:

Code: Select all

; int __fastcall main()
main            proc near               ; CODE XREF: sub_EA60+2F↓p

buf             = byte ptr -28h
bytes           = dword ptr -10h
argc            = dword ptr  4
argv            = dword ptr  8
envp            = dword ptr  0Ch

                push    60
                call    sub_E090
                push    ebx
                push    ecx
                push    edx
                sub     esp, 1Ch
                push    40h
                push    2
                push    offset aCAutoexecBat ; "C:\\AUTOEXEC.BAT"
                call    sopen
                add     esp, 0Ch
                test    ax, ax
                jge     short loc_E047
                mov     eax, offset aCAutoexecBat ; "C:\\AUTOEXEC.BAT"
                call    perror
                mov     eax, 1
                jmp     short loc_E080
; ---------------------------------------------------------------------------

loc_E047:                               ; CODE XREF: main+24↑j
                lea     ebx, [esp+28h+bytes]
                push    ebx             ; bytes
                cwde                    ; handle
                mov     edx, 20         ; count
                mov     ecx, ds         ; buf
                lea     ebx, [esp+2Ch+buf] ; buf
                call    _dos_read       ; Correct signature
                mov     eax, [esp+28h+bytes]
                mov     [esp+eax+28h+buf], 0
                mov     eax, esp
                push    eax
                push    offset aCAutoexecBat ; "C:\\AUTOEXEC.BAT"
                push    [esp+30h+bytes]
                push    offset aReadTheFollowi ; "Read the following %u bytes from %s:\n%"...
                call    printf
                add     esp, 10h
                xor     eax, eax

loc_E080:                               ; CODE XREF: main+35↑j
                add     esp, 1Ch
                pop     edx
                pop     ecx
                pop     ebx
                retn
main            endp

And for the crashing version:

Code: Select all

; int __fastcall main()
main            proc near               ; CODE XREF: sub_EA60+2F↓p

var_24          = byte ptr -24h
bytes           = dword ptr -10h
var_C           = dword ptr -0Ch

                push    60
                call    sub_E08C
                push    ebx
                push    ecx
                push    edx
                sub     esp, 1Ch
                push    40h
                push    2
                push    offset aCAutoexecBat ; "C:\\AUTOEXEC.BAT"
                call    sopen
                add     esp, 0Ch
                test    ax, ax
                jge     short loc_E047
                mov     eax, offset aCAutoexecBat ; "C:\\AUTOEXEC.BAT"
                call    perror
                mov     eax, 1
                jmp     short loc_E07B
; ---------------------------------------------------------------------------

loc_E047:                               ; CODE XREF: main+24↑j
                cwde                    ; handle
                lea     ecx, [esp+28h+bytes] ; bytes
                mov     ebx, 20         ; count
                mov     edx, esp        ; buf
                call    _dos_read       ; Incorrect signature
                mov     eax, [esp+28h+bytes]
                mov     byte ptr [esp+eax+0], 0
                mov     eax, esp
                push    eax
                push    offset aCAutoexecBat ; "C:\\AUTOEXEC.BAT"
                push    [esp+30h+bytes]
                push    offset aReadTheFollowi ; "Read the following %u bytes from %s:\n%"...
                call    printf
                add     esp, 10h
                xor     eax, eax

loc_E07B:                               ; CODE XREF: main+35↑j
                add     esp, 1Ch
                pop     edx
                pop     ecx
                pop     ebx
                retn
main            endp

So, what's the story? The function signature for _dos_read is:

Code: Select all

_WCRTLINK extern unsigned _dos_read( int __handle, void _DOSFAR *__buf, unsigned __count, unsigned *__bytes );

When defined correctly, as it is in <dos.h>, the _DOSFAR macro indicates that this is a far pointer, with segment and offset to be passed separately. So, when using the fastcall convention (as Rayman does), Watcom passes around the arguments as follows:
__handle is in EAX
__buf (segment:offset) is in CX:EBX
__count is in EDX
__bytes is pushed on the stack

But, if <dos.h> is omitted, then there is no prototype for _dos_read, and, not knowing that one of them is a far pointer, the compiler just assumes the four arguments go here:
__handle is in EAX
__buf (offset only) is in EDX
__count is in EBX
__bytes is in ECX

Of course, the compiler generates a warning if it can't find a prototype for the function, but compiler warnings can (but shouldn't!) be ignored. Evidently, this is exactly what happened at Ubi Soft during the development of Rayman v1.21 US: somebody accidentally removed a #include <dos.h> somewhere, and ignored the resulting compiler warning!

I suspect that the omission of INTRO.DAT and CONCLU.DAT was a direct result of this, and not to save space on the Rayman Gold / Forever discs. Whereas, for v1.21 FR, the error is fixed, so in that case the omission of those files genuinely was to save space on the Rayman Collector disc.


Well, that really was a long post! Thanks for reading, and I hope you found it interesting!

[dr_st]

Wow, what an amazing analysis, Plum!

You think you know about something, and then it turns out you've only barely scratched the surface.

In the course of this work, I have come to the conclusion that the earliest and rarest versions, v1.00 and v1.10, are EVIL!

So, I wanted to know - have these versions ever been released? Because I'm pretty sure I have one of the early original releases, and it already has 1.12. I have never seen anything before 1.12 on a CD anywhere.

Could it be that these early versions were intended for developers only, and that's why they put so many checks there (to protect against leaking?) which were gradually patched out in official releases?

Of course, the compiler generates a warning if it can't find a prototype for the function, but compiler warnings can (but shouldn't!) be ignored. Evidently, this is exactly what happened at Ubi Soft during the development of Rayman v1.21 US: somebody accidentally removed a #include <dos.h> somewhere, and ignored the resulting compiler warning!

You are completely right about the general mindset. In fact I try to compile many projects with -Wall -Werror by default, just for this reason.

However, in this particular case - it always BOGGLED my mind why this crap - "type undefined, assuming int" is considered a warning, not an error in the first place. I don't know any other language where missing definitions are considered a mere warning. There must be some reason for this, which the developers of the standard thought about, but I am not sure it was a good tradeoff in the end!

[RayCarrot]

Really interesting!

Just think about that for a second. If your BIOS doesn't match the one used by the developers, the game will not work properly.

I'm wondering, could it be that the game installer checks for your current system's checksums on install and then writes that into the .wld files when copying over the files from the disc? If so this check might be there to prevent an already installed game from being copied onto another computer. Then it also explains why it wouldn't check that if running directly from the disc as the .wld files wouldn't have been edited then.

So, I wanted to know - have these versions ever been released? Because I'm pretty sure I have one of the early original releases, and it already has 1.12. I have never seen anything before 1.12 on a CD anywhere.

Version 1.10 was never officially released as far as we know. Rib found it in a missprint of a 2013 version of Rayman Collection out of all things... It was on there as is without DOSBox or any way to run it. Version 1.00 I believe has an official release though, just that it's very rare.

[PluMGMK]

Wow, what an amazing analysis, Plum!

Really interesting!

Thanks guys!

Just think about that for a second. If your BIOS doesn't match the one used by the developers, the game will not work properly.

I'm wondering, could it be that the game installer checks for your current system's checksums on install and then writes that into the .wld files when copying over the files from the disc? If so this check might be there to prevent an already installed game from being copied onto another computer. Then it also explains why it wouldn't check that if running directly from the disc as the .wld files wouldn't have been edited then.

Yeah, as soon as I went to bed after writing that I realized that this was probably the case. I then felt embarrassed since the only reason it tripped me up was that the two of us were doing exactly what that DRM was designed to prevent! It's the same thing as in Windows 7, where a "hardware change necessitates reactivation", or whatever the wording is… Even so, it's still pretty evil, since it hangs your machine with no explanation why. It could result in a situation where you upgrade your graphics card, and suddenly Rayman starts acting weird, so you might think the new hardware is faulty.

EDIT: OK, so having disassembled the CONFIG and OS2_CONF EXEs from the disc images, I can confirm that it does indeed calculate the checksum at install time, and modify the installed WLD files accordingly. It also only checks the first page (4096 bytes) of each ROM, not the entire thing, so it should still work if you (for example) install the game on Windows then play on pure DOS, or vice versa. All right then, it's not as bad as I thought, but still… Hanging the machine with no explanation… It's not nice!

It's interesting that the game EXE for v1.00 is an uncompressed Linear Executable, whereas with v1.10 it's a compressed PMW1 like all the newer versions. But then, for both, the installers (CONFIG.EXE and OS2_CONF.EXE) are uncompressed, even though they were also compressed in the newer versions. It's also interesting that v1.10 has both CONFIG.EXE, which is started by INSTALL.BAT and runs on DOS / Windows, and OS2_CONF.EXE, which (as the name suggests) only runs on OS/2. Both calculate the BIOS and Video BIOS checksums, and I'm not sure what the differences in behaviour are, apart from detecting the OS… Later versions also had an OS2_CONF.EXE, but in many cases it was the only installer, and was intended to run on all supported OSes.

I wonder why there seems to have been so much effort put into supporting OS/2. It was only ever advertised as a DOS / Windows game, right?

Version 1.10 was never officially released as far as we know. Rib found it in a missprint of a 2013 version of Rayman Collection out of all things... It was on there as is without DOSBox or any way to run it.

Ah yes, I'd forgotten that story! I wonder if that CD has the exact number of sectors the game looks for… I see you sent me the image by PM, thanks for that! I'll take a look shortly…
EDIT: Yes, it has the right number of sectors, which means they must have pressed the exact image that was made back in 1995!

Hmm… A cursed prototype showing up in modern times, with no emulator to play it… This is starting to sound familiar

[RibShark]

So, I wanted to know - have these versions ever been released? Because I'm pretty sure I have one of the early original releases, and it already has 1.12. I have never seen anything before 1.12 on a CD anywhere.

Version 1.10 was never officially released as far as we know. Rib found it in a missprint of a 2013 version of Rayman Collection out of all things... It was on there as is without DOSBox or any way to run it. Version 1.00 I believe has an official release though, just that it's very rare.

Yep, we still haven't found an "official" 1.10 (aside from demo versions), the version I dumped indeed comes from a misprint of Rayman Collection, but since it was on a DVD, there were no audio tracks and so the disc did not validate at all. The version with the audio tracks that is floating around is a hacked dump I made just to get it running, by merging the audio tracks from the 1.00 version (which IIRC were the same sector length that 1.10 is looking for).

1.00 was released officially, I believe I have mostly seen these discs coming from France and Italy. The easiest way to tell whether an original disc is 1.00 is to look above the Ubi Soft logo on the disc. If there is one Moskito, it's the 1.00 version, if there are two, it's one of the later versions.

[PluMGMK]

it was on a DVD, there were no audio tracks and so the disc did not validate at all. The version with the audio tracks that is floating around is a hacked dump I made just to get it running, by merging the audio tracks from the 1.00 version (which IIRC were the same sector length that 1.10 is looking for).

Ah yes, it works perfectly, thank you for this work! It's so bizarre though, I wonder how they even got that image onto a DVD…

[dr_st]

Yep, we still haven't found an "official" 1.10 (aside from demo versions), the version I dumped indeed comes from a misprint of Rayman Collection, but since it was on a DVD, there were no audio tracks and so the disc did not validate at all.

I assume this is the collection in question?

You mentioned 'misprint', so I suppose not all copies of this release include the 1.10? Any way to know which do and which don't?

[RibShark]

Yep, we still haven't found an "official" 1.10 (aside from demo versions), the version I dumped indeed comes from a misprint of Rayman Collection, but since it was on a DVD, there were no audio tracks and so the disc did not validate at all.

I assume this is the collection in question?

You mentioned 'misprint', so I suppose not all copies of this release include the 1.10? Any way to know which do and which don't?

Indeed, most copies of the release include the standard GOG version. I'm not sure there's a way to tell just looking at the outside of the box, but my copy is from the Netherlands/Belgium. The affected disc has 300075561 as a serial at the bottom.

[dr_st]

Indeed, most copies of the release include the standard GOG version. I'm not sure there's a way to tell just looking at the outside of the box, but my copy is from the Netherlands/Belgium. The affected disc has 300075561 as a serial at the bottom.

I got a copy of the same, and can confirm that it's the same "misprinted" 1.10 with no way to run it legitimately because of all the checks. Worse, it only contains Rayman 1, not Rayman Forever (the expansions are missing).

I might get an Australian copy of the collection, which, if I understand correctly, should contain the GOG version of Forever (probably with the butchered soundtrack too).

Now, the real question is - do I have the patience to work out a no-CD crack for this version 1.10, given the madness that Plum described.

[torfirion]

For history, a 1995 group complaining that the game was hard to crack: https://nfomation.net/info/1707256403.rayman.nfo

[Hunchman801]

PluM's precursors! They might have come across a lot of the stuff he rediscovered recently.

[retrololo]

Thanks @dr_st for the great work creating Rayman No-CD-Patches!

I stumpled upon this thread (and also the interesting article on your wordpress blog) by searching a patch for Rayman.

Since i own a german budget release of Rayman (version 1.20 by Pointsoft) i was in hope, that the patches for EU v1.12 or IT-SP-DU v1.20 should work, but it seems the binary is different from the other international releases.

I took a look at the file and it seems the values are shifted by 0x10 in contrast to the IT-SP-DU v1.20 patch. I tried patching the appropriate values and voilà - now it works perfectly without a CD. That's awesome!

I just wanted to share this information with you, in hope that it's helpful for others with obscure, budget releases!

Here are the changes in detail:

Code: Select all

Rayman (GE) v1.20 - Pointsoft budget release (EAN 4041261502250)

File size: 430,198 bytes (compressed), 934,930 bytes (uncompressed)

0x8FED8: 75 → EB
0x8FF07: 75 0F → B0 00
0x8FFC8: 01 → 00
0x8FFDB: 0F 84 71 01 00 00 → 90 90 90 90 90 90
0x8FFE9: 75 → EB
0x90003: 25 FF 00 → E9 A5 01
0x902CC: 53 → C3    (video file check)
0x9049C: 53 → C3    (RAYMAN.EXE check)
0x9067E: 74 → EB    (program filename check)

Keep up the great work!

[dr_st]

Wow, what an excellent post. Thank you very much for this info and the super-clear presentation. I've updated the blog post with information on your version.

[retrololo]

Glad you liked it! Keep up the great work, very interesting reads on your blog and in this forum!

[PluMGMK]

Here's something funny: last Friday, my car reached a total mileage of 131000 km as I was driving home, and that number felt oddly significant to me. Eventually I remembered that it's because Rayman's data segment usually gets loaded at address 131000h under vanilla Dosbox!

[Fifo]

Haha, it’s a good feeling isn’t it?