Code #8 does not match validation?

[SansForSSBU]

In your README, the code you got for #8 is "iW8UwOHpH8op"
When checking the hash, this doesn't match validation.

I had the same issue in my playthrough (https://github.com/SansForSSBU/synacor_challenge_playthrough)
I wondered if you know why it doesn't match?

[tmbarker]

I can't remember if I sourced my challenge binary from the same repo that you forked; have you confirmed that they are identical files? I do remember reading at one point that Eric tweaked the challenge binary slightly, so it's possible that there are a couple versions floating around out there.

It also could be possible that the challenge binary persisted in the repo that you forked was not the same version used by it's author to generate the code-hashes.

If they are in fact identical, I'm not sure about the cause of the mismatch, and would be curious to get an update if you resolve the issue. Code #8 was relatively straightforward, and easily verified by computing the relevant "path arithmetic", so I would be surprised if the binary was outputting spurious codes.

[tmbarker]

I just downloaded the challenge.bin in the repo you linked, and it is in fact identical to the one in my repo.

[SansForSSBU]

Hi, I've done a little more digging myself. Yep, we both got our binaries from the same place. We have the same "incorrect" code #8, which is why I'm so sure it was a mistake on the author's part in some way.

The user whose repo we both forked has another repo with their attempt at the challenge and this contains a binary that is different from ours. I tried using this binary, both by transplanting it into my solution and running the author's solution and it gets different codes for every step, not just the 8th. I think if a different binary was used in the solution, all of their validation hashes would have been wrong and not just the 8th one, unless the solution codes were generated using yet another version of the binary which only tweaked the 8th. Good shout to check though, I didn't consider that.
(https://github.com/Aneurysm9/challenger)

My current theory is that they bypassed the vault door. You can program your VM to just set the orb's value to 30 right before it's checked at the vault door and enter the vault despite not solving the puzzle properly. If you do that, the code you get from the mirror will depend on what route you took through the orb puzzle.

I sent them an email asking if I could have the solution code they used to get the codes for the validation hashes, I'll let you know if/when I figure this out.

[tmbarker]

Here is a comment I found on Reddit from Eric Wastl where he alludes to having changed the binary after OSCON 2012; unfortunately, he says he doesn't remember what he changed exactly.

As a sanity check, I'm going to manually verify the route my pathfinding code takes for puzzle #8. Thanks for looking into this, my curiosity has definitely been piqued.

[tmbarker]

I just manually verified my/our solution, and unsurprisingly it appears sound:

22 -> 26 -> 15 -> 60 -> 42 -> 31 -> 30

Next, I had the thought that perhaps there are many solutions to puzzle 8, each of which admits a different code. I modified my pathfinding code to skip the first/shortest solution, and to continue looking for longer solutions. I let the code run for ~30s, and no further solutions were found.

At this point I struggle to see how this solution could be incorrect.

[SansForSSBU]

EDIT: I figured it out. There's no mistake with the validation. If you want a hint, read the reddit thread you linked again carefully. Apologies for any spoilers if you saw my old version of this reply

[tmbarker]

Solved! Thanks for creating this issue, I never would have realized my final code was "incorrect"/incomplete otherwise.