Community
SCI Programming => SCI Syntax Help => Topic started by: lwc on October 01, 2023, 04:41:59 PM
-
Eco1 has a copy protected code. It's entered into the initial room's door's keypad.
The room is 400.sc and the keypad is 65.sc (aka keyStuff.sc).
Half the websites that mention eco1's copy protected code state it's 9721 while the other half state it's 9731.
The CD version removed the keypad scene completely (clicking the keypad is equal to clicking the door, which just opens it directly).
But the floppy version does something very weird:
- If you enter a random code, there's a red light but the door gets opened anyway
- If you enter the correct code, there's a green light and the door gets opened
Both provide exactly the same points too.
So my question was the Floppy's SCI code hacked into to make any code work? If so, why not just color every random code as green too? I've deleted all SCR files and still it was hacked.
- CD version v1.1 seems to still have https://github.com/sluicebox/sci-scripts/blob/main/eco1-cd-dos-1.1/src/keyStuff.sc but it's not called (from https://github.com/sluicebox/sci-scripts/blob/main/eco1-cd-dos-1.1/src/rm400.sc).
- Floppy v1.000 (which is what one usually finds online) has 9731 (not 9721) in https://github.com/sluicebox/sci-scripts/blob/main/eco1-dos-1.000/src/keyStuff.sc called from https://github.com/sluicebox/sci-scripts/blob/main/eco1-dos-1.000/src/rm400.sc
- Floppy v1.1 (which I've never seen anywhere) also has 9731 (not 9721) in https://github.com/sluicebox/sci-scripts/blob/main/eco1-dos-1.1/src/keyStuff.sc called from https://github.com/sluicebox/sci-scripts/blob/main/eco1-dos-1.1/src/rm400.sc
Both floppy versions do so via rm400.sc's:
(self setScript: (ScriptID 65 0) self) ; keyStuffIf their code mention 9731 (see screenshot) how come every code works too? And what controls the red/green light?
-
If local11 is 9731, flag 14 is cleared. So script 65 local11 is theCode and flag 14 is dolphinRoomLocked. If you get the combination wrong, keyStuff says that's not the right code, exits, does not clear the flag, and script 400's toDolphinRoom exits early. At least, that's the intent.
(The light turns green or red because of (led cel: (if (== local11 9731) 2 else 1) init:) in enterScript.)
Places where flag 14 is set (door is locked):
- keyStuff state 0
- keyStuff state 5 (failed)
- rm400 fromDolphinRoom
Places where it's cleared (door is unlocked):
- keyStuff state 4 (success)
Places where it's checked:
Not a lotta places where it could go wrong. And by all means, it works as intended in the 1.10 version I have but not 1.00. Yet for all intents and purposes their scripts are the same.
-
If their scripts are the same and not a lotta places where it could go wrong, how come it's hacked in v1.000?
Was this game released on Floppy with a failed copy protection which was only fixed in 1.1 (while at the same time was removed altogether for CD v1.1)?
-
That's the thing, isn't it? You call it hacked, but the scripts seem perfectly fine and at least none of the patches in my copies affect these two rooms. It's a gosh darn mystery. I've done a global search and those are the only places where that flag is used. Only the CD version didn't give me the same search results, but you know why.
-
It's just as mysterious to me why so many reviews or even walkthroughs falsely state the wrong code, not to mention some of those guides state "you must enter the right code or it won't work" as if they didn't even try it.
-
I used to know the answer to this. When I did the EQ1 restoration I enabled the keypad for the CD version. As you mentioned the script is still there, but if you wire it back in through script 400 it's buggy. I recall it allowed any code like the floppy versions (not sure) and clicking outside the keypad area would crash the game. I can't remember how I fixed it, but I always figured the reason the keypad was removed from the CD version was because they didn't have time to solve the crash - they added it back in the Discovery series edition.
FYI, the game included a newsletter that has the code written in the margins. Maybe those sites had trouble reading the sideways text and, since any code works, they assumed 9721 was the correct code.
edit: I've attached the 65.scr and 400.scr that restores the keypad in the CD version. If only 400.scr is used the game crashes when clicking outside the keypad, but rejects bad codes. They must have fixed the wrong code bug before removing the keypad.
-
It's been cracked alright (that branch instruction at 0CCF has been rendered ineffectual):
[...]
0CC9: lsl local_11
0CCB: ldi 2603
0CCE: eq?
0CCF: bnt lbl_0CD2
lbl_0CD2:
0CD2: push1
0CD3: pushi 0e ; selector <lsLeft>
0CD5: calle 0333 0004 02
0CDB: pushi 008d ; selector <cue>
[...]
(that's the version that came from Jimmy Maher's site here (https://www.filfre.net/2018/10/the-sierra-discovery-adventures/).
-
That screenshot above is even more of a mystery. It states the code with 3 no less than 3 times (some of which in a very large font), and still thousands of sites got confused and thought it's 2?
The version from Maher's site is the the Internet standard one (v1.000).
In your attached CD files, if both are used does it reject bad codes?
And would you like to add to that ZIP the same files for Floppy v1.000 which accepts bad codes?
And will ScummVM still bypass those codes unless the --copy-protection command line parameter is used?
P.S.
Can you add source code to that ZIP and/or explain what you changed?
-
That screenshot above is even more of a mystery. It states the code with 3 no less than 3 times (some of which in a very large font), and still thousands of sites got confused and thought it's 2?
The version from Maher's site is the the Internet standard one (v1.000).
In your attached CD files, if both are used does it reject bad codes?
And would you like to add to that ZIP the same files for Floppy v1.000 which accepts bad codes?
And will ScummVM still bypass those codes unless the --copy-protection command line parameter is used?
P.S.
Can you add source code to that ZIP and/or explain what you changed?
I had some data loss around the time I made the CD patches and lost the source. I don't remember the exact changes. Yes, using patch 65 and 400 makes the keypad fully functional in both DOSBox and ScummVM. You don't need to use --copy-protection.
-
That's kind of a bug in ScummVM then since all numbers should work unless --copy-protection is used.
The problem is I can't submit this since officially (unless someone finds Floppy v1.1) the game was shipped without a working copy protection.
-
SVM has had a policy to skip copy protection fro games that also had an official release without, i.e. CD releases vs diskette releases.
BTW, if you are looking for version 1.1 it is the Sierra Discovery Series release.
-
But it's not supposed to skip them if the aforementioned command line parameter is used. Anyone with access to that Floppy v1.1 version please check with and without that command line. This is based on the post above that stated v1.1 actually uniquely blocks wrong codes (but it didn't mention how was it played)
-
If you mean my post, that was the Discovery edition, SCIDHUV on DOSBox.
-
Thanks! If it natively blocks wrong codes could you try it in ScummVM with and without that command line?
BTW, is that manual online? Most archives have just the general technical manual.
-
scummvm ecoquest-1-disco: red light, message, door remains closed.
scummvm --copy-protection ecoquest-1-disco: exactly the same.
No saves, no skipping the gull cleaning intro, and most of all neither run accepted 1337.
I tested my copy of EQ1 1.0 in German just now for a laugh and it too won't let me in. That was SCIDHUV on DOSBox btw.
-
BTW, is that manual online? Most archives have just the general technical manual.
It's scanned on this wiki (https://ecoquest.fandom.com/wiki/Adam%27s_Eco_News), even has your 9721 code in the description.
I would not want Scumm to 'fix' that bug, at least not for my CD patch files. That would negate the entire point of restoring the keypad.
I personally don't think Scumm should be bypassing any copy protection by default. The protection is part of the experience. Just memorize all of the PQ2 mugshots like I did.
-
No saves
Really? Is this version also unique in not letting save in the first room?
no skipping the gull cleaning intro
Do other versions let you skip it? If so, how?
and most of all neither run accepted 1337.
What do you mean?
It's scanned on this wiki (https://ecoquest.fandom.com/wiki/Adam%27s_Eco_News), even has your 9721 code in the description.
You're right, it's the upside down part, thanks! Now fixed in the wiki.
I would not want Scumm to 'fix' that bug, at least not for my CD patch files. That would negate the entire point of restoring the keypad.
I personally don't think Scumm should be bypassing any copy protection by default. The protection is part of the experience. Just memorize all of the PQ2 mugshots like I did.
I don't think Eco1 should be the only game out there to not follow ScummVM's verdict. Everyone can always use the command line parameter. Besides, you can permanently use it this game's section in ScummVM's INI file so the game will always use it.
But rest assured it's very unlikely they'll dare to bypass your patches as they refuse to grant any special support for non official files.
-
The problem is I can't submit this since officially (unless someone finds Floppy v1.1) the game was shipped without a working copy protection.
Have you confirmed the bug with an actual floppy version of EcoQuest v1.000, not just one downloaded from the internet?
-
Really? Is this version also unique in not letting save in the first room?
No saves as in it does let me save in the first room, but I didn't use any in case --copy-protection was implemented in such a way it'd cause interference with the save.
Do other versions let you skip it? If so, how?
I meant I sat through the entire sequence. As far as I know, no versions let you skip more than the title sequence.
What do you mean?
I mean I used 1337 as an obviously wrong access code to test if it'd accept it or not. Neither run did. EcoQuest 1.1, the Discovery Edition, has a perfectly functional door lock no matter what you pass to ScummVM on the command line.
-
The problem is I can't submit this since officially (unless someone finds Floppy v1.1) the game was shipped without a working copy protection.
Have you confirmed the bug with an actual floppy version of EcoQuest v1.000, not just one downloaded from the internet?
You're right, random codes are blocked if you install through floppy installation files. This can be confirmed thanks to the Internet Archive, which hosts eco-quest (that's how this specific archive is spelled, as I probably shouldn't link directly) with 4 ZIP files, one for each disk. It can be installed via DOSBox by mounting a general folder, then copying the files from the first disk there, installing until the next disk is requested, then emptying the folder and copying there the next disk, clicking enter inside the installation to process the next disk and so on. Once done, in both DOSBox and ScummVM (even without the command line parameter) the copy protection can't be bypassed.
This confirms the very reason I've opened this topic in the first place - it means the Internet Floppy v1.000 was indeed hacked. Not by SCR files though, so I suspect by modifying the RESOURCE files directly. I wonder if the CD version was hacked too, just in a different way.
-
so I suspect by modifying the RESOURCE files directly. I wonder if the CD version was hacked too, just in a different way.
Even with the volume-level compression?
-
Looks like it. The resources are identical between the cracked and original v1.000 except for one byte at offset 0x5da2 in RESOURCE.000. The crack changes 0xC0 to 0x00.
edit: Also did a quick search of the ScummVM repo and didn't see anywhere that SCI is using the --copy_protection flag, maybe the SCI engine isn't disabling copy protection for any game?
I don't think the EQ1CD version was cracked. I believe they either didn't have time to fix the keypad crash or they didn't want to pay to include the EcoNews feelie with the CD.
-
... Woah.
-
Note that the he Internet Archive has a lot of games that are of warez origins. They also have a number of releases that are 'preinstalled' using my installers. CD-ROM images there are more likely to be unadulterated images. That does not invalidate it as a source for versions you are looking for, just beware that it may not be untampered.
The CD version was not cracked because it had no CP.
-
That's impressive. And I can confirm that reverting 00 -> C0 does make the protection functional again.
-
It I recall correctly, it was pretty common practice at Sierra to remove (most) copy protection schemes from CD versions of their games. Al Lowe even remarked on it in an old interview somewhere that they did it because (at the time) the CD versions were just so big they wouldn?t be casually copied/distributed like the floppy versions were.
And hacked versions were also pretty common for a bunch of games which have unfortunately become kinda the defacto versions still found on abandonware sites today. Gold Rush and Colonel?s Bequest are two notable ones that come to mind.
-
Looks like it. The resources are identical between the cracked and original v1.000 except for one byte at offset 0x5da2 in RESOURCE.000. The crack changes 0xC0 to 0x00.
I knew the smart people here will crack (no pun intended) the case! Any way to know what was changed in source code?
I don't think the EQ1CD version was cracked. I believe they either didn't have time to fix the keypad crash
Which crash is that? The only crash that was discussed here was related to brand new fan patches.
-
I knew the smart people here will crack (no pun intended) the case! Any way to know what was changed in source code?
Nothing. This is a change to not only compiled code, but a compressed data stream of it. How someone came up with this patch, we'll never know, but ingenious it is.
-
Still better than what they pulled with Colonel's Bequest, diking out the interpreter's randomizer...
*un-cracks his Eco*
-
Which crash is that? The only crash that was discussed here was related to brand new fan patches.
Yeah, I meant the CD version crash when clicking outside the keypad. I assumed that might have been why they removed it, but as Charles said, it was just as likely removed because CDs were considered impractical to copy at the time.
-
This is a change to not only compiled code, but a compressed data stream of it. How someone came up with this patch, we'll never know, but ingenious it is.
Couldn't they have opened the game in something like SCI Companion, do the change, then compile it back to the RESOURCE files?
-
That depends on how old the cracked version is, and if the tool (which may or may not be SCI Companion) supports re-packing.
-
Some of these tools are quite old (although old is a relative term). Could you compare 65.sc from the common cracked version VS the pure v1.000 version and see if there's a noticeable difference?
-
Comparing the cracked decompilation of script 65 to the repaired version I get this interesting difference. Noticeable indeed!
(I should note that instance d0 of Prop was named just d in the cracked version, but that's not relevant. The only other difference besides that is in the screenshot.)
Edit: In disassembly terms, it's a bnt that had its target changed from 0x30 to 0x00, so it ran the "correct code" block either way.
-
Nice! So did they just remove the if/else clause?
What does the leftover (== local11 9731) do when it's not inside an if clause? We do know elsewhere in the code it still flashes red.
-
It does nothing but set some internal state on the PMachine for a better-formed branch to consider. All this branch would do is either clear the "door is locked" flag and dispose of the inset, or narrate that you entered the wrong code.
So the if/else is still there and is executed, but both true and false paths lead to the same code block: true. So the lock is cleared and the inset disposed.
The flashing and such is handled completely separately, with its own comparisons to determine the led color and sound effects, in earlier states of enterScript.
-
So what was the exact change in source code that allowed random codes?
-
It wasn't changed in the source code.
-
So did they change both the binary and removed the else line from the source code? Sorry, just trying to understand.
-
They never had the source code and edited the PMachine bytecode in the script resource, the SCR file directly. I'd be willing to bet this cracked version far predates any SCI Companion with a decompiler they could've used.
Part 1
PMachine: Load the entered code, load the correct code. See if they match.
Script equivalent: (== local11 9731)
Part 2
PMachine: If the last condition is not true, skip over 0x30 bytes from here, to the B block. Implicitly, if it was true, continue to the A block, which is the next 0x30 bytes worth of code.
Script: (if <the part I just described> <A block> else <B block>)
Part 3
A block: clear the "door locked" flag, cause the keypad inset to dispose, then jump to the end of the method.
Part 4
B block: make the Narrator say that was wrong, then jump to the end of the method.
The interpreter, when running this, sees the bnt opcode and blindly follows orders. If the code doesn't match, skip over A block to B. The narrator says you're wrong. If it does match, don't skip ahead and continue on to A block, unlocking the door.
In the hacked version, part 2 is changed to jump zero bytes instead, so it runs A block either way: (if (== local11 9731) <A> else <A>). The interpreter never gets to even consider the code in B block, it's never run.
Now look at it from a script decompiler's point of view. In the "clean" version, it can tell there's two distinct paths and emits (if (== local11 9731) <unlock and dispose> else <complain>).
In the hacked version, they're both the same path and it too never gets to even consider the code in B block. The condition effectively cancels out and only the part that's actually logically possible to ever run is decompiled. And since it canceled out, why bother with the "if" block?
But it already considered the expression being evaluated, so that stays behind. (== local11 9731) <unlock and dispose>.
If they did use source code editing, the entire B block would've been missing and everything that came after would've shifted up in the bytecode. It's still there, so they didn't.
Edit: to clarify, every single "source code" version we've been looking at so far was our own decompilations. Because we don't have The Actual Source Code as written by the Sierra programmers. All we have is bytecode.
-
What I still don't understand is who changed that source code. You shows a comparison in which one part was without the else clause.
-
Again, nobody changed the source code. Whoever cracked the keypad to accept any code did so directly in the PMachine bytecode, basically editing the SCR file, no SC in sight. All script code shown in this entire thread is from our own decompilations, both from the cracked version and the original.
I won't explain where the else clause has gone again, nor why it's gone.
-
Lwc, I think the fact is you probably need a better understanding of the relationship between bytecode, assembly, source code and the compile/decompile process before this will really make sense. It's something I've personally been studying for months and still have a lot to learn.
It would probably be helpful to start learning some assembly in DOS first, then you can better understand the SCI Interpreter nuances. There are some really good SCI-specific resources on the SCIWiki (http://sciwiki.sierrahelp.com/) such as this list of VM instructions (http://sciwiki.sierrahelp.com//index.php?title=SCI_Specifications:_Chapter_5_-_The_SCI_Virtual_Machine).
-
Before Companion 3 there were no decompilers. Brian had hand decompiled an SCI game (LSL2?) to make the original fan SCI template game and create his SCI Studio script. Even then he had to fall back on assembly to fill in the gaps. So there was no source editing EQ1 when it was cracked. The fan tools we had before SCI Studio were mostly limited resource extraction, viewing, disassembly of SCR files, etc. This is why Phil's SCI Companion 3 is such a hall mark in fan SCI tools. The we are also blessed with leaked official SCI documentation, SC code and systems scripts. This allows us to now use the Sierra scripting language in SCI Companion 3.
BTW, this is not the first time that a Sierra game has been cracked with a hex editor. The infamous Gold Rush! crack did this, but missed things that didn't allow the house buyer to show up if the game speed was set too high. TCB and a number of other ones were originally crack this way, too. The curious thing is that even Sierra cracked their CPC protected AGI games this way too, for inclusion on the various collection CDs
-
By the way, I decided to look into it on a whim and ScummVM's SCI engine doesn't react to --copy-protection at all. I checked. The only engines that do are AGOS, Dreamweb, Gob, Lure, MADS, Saga, SCUMM, Voyeur, and Xeen.
So it really doesn't matter which version of EcoQuest 1 you play in ScummVM -- the hacked 1.0 will always accept any code, the legit 1.0 and 1.1 will not, and the CD version will skip the lock entirely, no matter if you tell ScummVM to bypass any copy protection because the SCI part of ScummVM doesn't care about that feature.
If it should or not is a completely different topic for a different thread.
-
Before Companion 3 there were no decompilers. Brian had hand decompiled an SCI game (LSL2?) to make the original fan SCI template game and create his SCI Studio script.
It was LSL3.
-
You can tell this is true because both LSL3 and the template game have a "Colors" menu item.