How does EcoQuest 1 allow to enter any code and not just the copy protected one?

[lwc]

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?

[Kawa]

That depends on how old the cracked version is, and if the tool (which may or may not be SCI Companion) supports re-packing.

[lwc]

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?

[Kawa]

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.

[lwc]

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.

[Kawa]

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.

[lwc]

So what was the exact change in source code that allowed random codes?

[Kawa]

It wasn't changed in the source code.

[lwc]

So did they change both the binary and removed the else line from the source code? Sorry, just trying to understand.

[Kawa]

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.

[lwc]

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.

[Kawa]

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.

[doomlazer]

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 such as this list of VM instructions.

[Collector]

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

[Kawa]

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.