I’m going to laugh my ass off if that grilledpizza.jpg image was the final ‘real’ puzzle (“congratulationsyouwonthePIZZA”) and the rest of this is just Storm fucking with us. I don’t think it is for a second, but I would still laugh my ass off all the same.
I would probably cry instead.
But the PIZZA is a LIE, therefore you won the LIE, unless it was double bluff, and actually the LIE is the truth and that was the end of it.
Yep. That was a necessary thing to do as the number of ciphers and modes increased in my program.
My block cipher inner loop actually runs 123,887,616 times. It would be impossible to check that by hand 
In order to compile that, you may need to replace wchar_t by char in the main function. Also you’ll need to specify it’s c++11 to gcc somehow. Also, in addition to removing hash loops, you should to replace
[code]string Key;
Key.resize(pHash->DigestSize());
pHash->CalculateDigest((byte*)Key.data(), (byte const*)Phrase.data(), Phrase.size());[/code]
by
[code]string Key = Phrase;
//Key.resize(pHash->DigestSize());
//pHash->CalculateDigest((byte*)Key.data(), (byte const*)Phrase.data(), Phrase.size());[/code]
in both loops. I guess you figured that out anyway, but I’m writing that just in case.
If I understand correctly this would make the code not to perform the hash on the password and just use the Password in its hex form as a key, padded with zeros if neccesary.
Still I think we are missing something to solve this. The last clue, the 64 code, at this point I don’t think he is trying to distract us with red herrings, the thing is, what to do with it if it is not a ciphered text?
Maybe it is runnable code in some weird scripting language (thinking of Befunge and the like).
Or, as Stormseeker said it:
“There is an answer, but you can’t brute force it, the CIA couldn’t brute force it. Someone is already close.” “How do you know solving this has anything to do with encryption?”
I’m no expert on ARGs, but I think this is a red herring that you’re over-thinking a bit.
(Assuming a UK keyboard layout from here on.)
Imagine someone intentionally trying to type gibberish after ‘leptons have a mi’. With their left hand down by the asdf part of the keyboard, occasionally reaching up to 1 and 2 and pressing shift in and out, and the other hand positioned with the fingers spanning the numbers 6, 7, 8 ,9 and 0, tapping away in an attempt at randomness.
Notice the sequence ‘0976’ is immediately followed by the identical sequence but shifted (and is repeated in a slightly different order later), and the next couple of dozen chars are those same shifted numbers interspersed with shifted a, s, and f. Then shift goes on and off for a bit with the same numbers, and lastly shift is held down again and the numbers under the right hand are now interspersed with shifted 1 and 2, where the left hand must have reached up to. If you could program a keyboard to light up those keys in sequence, I think you’d plainly see someone tapping away in an attempt to simulate corrupted gibberish.
EDIT: For what it’s worth, here’s the keys pressed, without shift applied:
7s6d09760976a0s90f 90a6sf0 a9076 609as76 966097609760982-02-09820981209812091280
Assuming my thesis on hand placement is correct (and space is pressed with the left hand), you can split it up into two sequences:
Left hand - sdasf asf a as 222121212
Right hand - 76097609760909060906090766097696609760976098-0-0980980980980
Five occurrences of ‘0976’ alone, and four or ‘098’ at the end.
Shift is pressed three times: held on for a while, released, and briefly pressed and released again, then held on for the rest.
Valid point. This is entirely possible (probable, really), and makes sense. So perhaps we should be digging into the actual overall meaning of the “clue” rather than the intense scrutiny we’ve given the gibberish.
@AngelSG: Yes. I’m saying that because there’s no option to turn hashing off the way I coded it.
@raw_bean: That’s what I assumed from the beginning, that it’s just a random keypress gibberish, so I didn’t even look into that thing. But it was funny watching people go crazy over it with some cipher theories.
Perhaps the clue is in the fact that the message was corrupt and incomplete. What if this is supposed to tell us that the hex code is also incomplete or truncated? Perhaps this is what the “[ABORTIVE.]” string in HALOS.txt is hinting at.
If this is the case, the assumption that the hex code is a 64-bit block cipher falls apart and the 64-bit block size might have been a coincidence or a deliberate misdirect. So, maybe it is really a 128-bit block cipher and the last 128-bit block was cut in half in order to make us believe it was a 64-bit block cipher.
I really like this idea. Considering how many people have been attempting every possible key associated with the ARG, the game, and so forth, this is likely the case. The question is where we might derive those missing bits from.
The problem about this is searching for data that is apparently random, since the algorithm won’t produce words, ip numbers or anything intelligible. All block ciphers would decode at least the first blocks even if the last one was not complete, as long as those blocks were intact. More possible passwords, Danger Macroscale Quantum System or Macroscale Quantum System, it’s what is written on the doors of X01 and X02. It may have some relation since storm said that we should find “the niobium connection” and the quantum system is presumably were the Niobium was put to use.
Edit: If this might not have anything to do with encryption, may it be compressed? I mean, compressed files do have high entropy, while looking on the subject, apparently, it is hard to differenciate encrypted files from some compressed files based just on entropy. Even doing other stastistical tests it is hard and automated detection fails if the file header is removed, for the whole explanation:
https://www.devttys0.com/2013/06/differentiate-encryption-from-compression-using-math/
The problem is that 752 hex characters might not be a big enogh sample to get conclusive results 
Like AngelSG said, if it is only the last block that is “damaged” and is missing 64 bits / 8 bytes, and all the other (previous) blocks are intact, then we will be able to decrypt all the blocks except the last partial 128-bit block. It is possible that Storm formatted the message so that the last block only contains padding and/or characters that are not important to the message. My suggestion is that we simply discard the last 64 bits / 8 bytes of (the raw non-hex version of) the code when attempting to decrypt the code with 128-bit ciphers like AES. That way we avoid getting error messages from crypto tools/libraries (although they may still complain about incorrect padding).
However, if the missing 64 bits are at the beginning of the code and it was encrypted with a mode like CBC, where the decryption of one block depends on the decryption of the previous block, then we would probably not be able to decrypt it without the missing part. Unless it was encrypted with the ECB mode, where each block are encrypted individually, in which case we can just discard the first 64 bits / 8 bytes.
This is false. Especially CBC mode can easily be decrypted without leading blocks. You don’t even need the right IV.
Yes, you are right. While encryption in CBC mode has to be done serially from the first block, decryption can be done starting from any block (but you still need the encrypted block preceding the block you are starting from, though).
Well, yes, the point I wanted to make is that no matter the mode, even if the last block was split in half, the blocks that are not damaged will decrypt without problems, provided we use the proper key, so nobody loses time searching for something to pad at the end of the message and tries again every possible password.
Edit: I tried some software to see if the file presented an entropy characteristic of encrypted files or compressed files, but the sample is too small, so no luck with that.
Not particularly relevant, but here’s Valve talking about ARGs. Maybe inspiration lies within…
https://www.youtube.com/watch?v=VIAkqYCw6aY
There’s a lot of people solving them and are not very difficult, well, at least not for the amount of people trying to solve them, if there were “only” thousand people trying to solve the 752 code, it probably would be solved by now, maybe even with one hundred participants it would be solved by now. Nevertheless, interesting video.
Edit: By the way, I did not find anything on the forum, but did somebody try to search for stenographic information inside the Research and Careers pngs from bmrf.us?
Edit: I checked last night the images and did not find anything, but the fact that they’re commented out on the bmrf.us source code, and have the first and last characters substitued by a hash is still weird, red herring perhaps?
Late to the party here, so how’s the ARG going?
It seems to me that there are plenty of red herrings so to speak…