And if it’s supposed to be an actual bootloader, it is missing the magic value that is supposed to be there to be detected as a bootlader
Reposting this here, didn’t see the thread earlier. In short, I think equating the HEX codes to actual binary data is the wrong train of thought.
https://forums.etarc.org/t/phase-2-topic-2/1574/217?u=jedidia
I noted that somewhere above here as well, but added to that that one can actually consider them as a valid byte string as long as you take them in pairs of 2, since 7 + 7 = 14 pairs = 7 bytes.
Of course you can concat them all together, giving you a total amount of data of 3584 bytes. But then where does the numbering figure in? If we want to pursue this course, we’d have to find a way to map these 3.5 byte blocks to one byte each.
This is probably just another dead end.
There is no real need to consider these “byte-14399” as actual positions. One can also consider them as instruction (subtract from the byte), and they might even be totally meaningless.
Point is, until we find out what these hex codes actually mean (if they mean anything at all), then considering the possibility that they do combine into bytes in some way is only logical, even if it’s certainly not the only possibility.
That is of course true. My point was really just about the idea of searching for these codes in binary file data. We simply don’t have the necessary information right now to make such a search anything but a waste of time.
As for the codes meaning something, yes, that is entirely possible.
not necessarily, when you open a hex editor, you can actually overwrite 3.5 bytes (just the first half of the 4th), and 2 consecutive byte positions just means you take the second byte and overwrite most of what the first inserted. Still, that is possible. The only issue is that we don’t have any suitably candidate to apply these tricks to. There is nothing really standing out as a “look at me” kinda file.
The result of that would be identical with just taking the first two digits of every code… seems a bit too arbitrary, but it would constitute a mapping as mentioned above. But yes, we’d still be missing a file…
Well, if you only take the “empty hole” codes, there is only a single set that overlaps.
Huh… let me just check a few things real quick.
What about the notebook image itself. The bottom is completely masked, but there seems to be something written down and circled there.
Possible, the file seems to be ~1100kb in size, so that might work. I’m not entirely sure how these png images work, and if editing stuff at the beginning clears up the end, but it’s certainly possible. I’ll leave that to one of the graphics experts.
It is also worth noting that it appears to be a generated image (there is probably a .php or .asp script backing it).
So might be something on the alpha channel…? This pesky guys at Mercury are known to use also volume-maps… The texture atlases for terrain, inside the simulation do look a bit like the overlayed glitch… Got no access to pc, but if you look at asteroids.dds, (for example) in my memory it rings a bell… I had absolutely no luck modifying those, before anyone asks…
.DDS would seem like a good format to test…
Nah, nothingburger. Thought I might find some sort of commonality between the bytenumbering of the holes and the decimal value of the Hex code, but it doesn’t look very promising after a few preliminary looks.
I really think that overlaying the image physically over another image and cut out the wholes would be a more promising aproach, but we’re missing something to overlay it on even here.
welp, emails being sent out. Check your inboxes.
I’m pretty sure the hexcodes mean nothing. They appear to simply be the answers (When a person uses their paper code wheel to decrypt their unique code). Each code unlocks a “pixel” of the complete picture. Any leftover hexcodes are answers that were never submitted. The problem from a Hello Games perspective is that they have no idea how many people are going to participate. So they could tackle this by entering codes themselves if the turn out is low. If the turnout is high they could just have easy release multiple hexcode maps (overlays) for the same picture (your answer would dictate which overlay you saw). I suspect the later is what they did based on the fact that people were posting pictures of completed bootsectors (before the one I was on was completed).
This thread started before the emails and update on project-wt happened. Now in hindsight I think it’s safe to say that waking titan has moved in a different direction. So most likely you are correct. But regardless, I think it’s safe to park this thread in the garage for now… unless HEXes pop up again later on any of the websites.
So you think the deliberate blank spaces mean nothing? I’m not sure I buy that.
1 Like
They’re not intentionally blank. I know when I entered my answer it highlighted my hexcode answer and the “pixel” it unlocked in cyan. That mechanic isn’t unique to me. It happened to everyone that entered a code. You can’t ignore the unknown variable in this puzzle. Going into this, there is no way Hello Games or anyone else on the planet could know how many people would participate in this. What you’re suggesting here is that we got 100% participation. We got exactly the precise number of participants to unlock everything except a few squares that were “intentionally left blank” as a “side quest” by Hello Games.