[ARG] The Pizza Code Mystery

ECB mode is the simplest mode of operation that can be used with a block cipher. Other modes use a so-called initialization vector (IV) which is unknown to us. However, it is possible that the IV is part of the (hex decoded) code, for example the first or the last block could be the IV. The IV doesn’t have to be secret, and it is therefore often sent along with the encrypted data.

If Storm used a block cipher in ECB mode, then we can most likely rule out 128-bit (and larger) block ciphers, because 16 (128 bit) doesn’t evenly divide 376. This is assuming the coded data is complete and nothing is missing from the code.

On the other hand, if it is a 128-bit block cipher, then we can rule out ECB mode and we need to look at the stream cipher modes CFB, OFB and CTR.

The CTR mode is a bit different from the others in that it uses a counter which is incremented for each block. The initial counter is usually initialized with an IV like the other IV-based modes. In some cases this counter is split in half where the left half is initialized with a value called a nonce, and the right part is initialized to 0 or 1. For a 128-bit block cipher the nonce could be 8 bytes, and maybe the first 8 bytes of the code is the nonce.

Ever since the block cipher idea was suggested, the problems has always been determining the block cipher, block size, mode of operation, possible IV and key size. And then there is the question of how to transform a possible password to an actual key that can be used with the block cipher. This transformation is usually done with a key derivation function, which in the simplest form can be a simple hash function. Or, the key is simply the ASCII encoding of the password, padded or truncated to match the key length.

DES and TripleDES have an additional complication in that the key have bits that are not part of the actual key bits. These bits are called parity bits and are used for detecting simple bit errors.

One thing that has stuck out to me from 0418_08151814’s PM to Guns, is this:

I don’t know if 0418_08151814 ever mentioned 64-bit block ciphers in earlier PMs to Gunsrequiem, but it is curious that he briefly mentions the block size analysis resulting in 64 bits, but then completely omits 64-bit ciphers from his discussion and only brings up 128-bit and 256-bit block ciphers. For example:

But later, he says:

Maybe he is actually telling us exactly what we need to do here, and that we shouldn’t blindly trust everything he saying in his PM, but trust our own analysis of the code, work out the block size, modes and key lengths, and while doing so, we should probably make a few assumptions that might help narrow things down a bit, and work our way out from that.

One of the assumptions we could make is that the code is complete and isn’t missing any parts. However, there are clues that contradict this. For example, what if [ABORTIVE.] and the “data corruption” in other clues means that the code has been cut off at the end? We can still decrypt the partial message, but it means that any block size analysis is meaningless. So, we are back to square one.

We can choose to trust 0418_08151814’s suggestion that it is either 128- or 256-bit AES or Rijndael. But then in another hint we find: “Don’t trust anyone, it’s not safe.”

So, there are a lot of unknown variables that we just can’t seem to figure out or narrow down.

Great stuff here, man!

Here’s the thing–those PM’s came at a time when Storm already knew that I was suspicious of Code_ /0418. Here’s the rest of the messages following up to that point:

"Code_,

I previously mentioned that the “seek out Code_ he is watching” message may have pertained to you, but I never went through with actually attempting to do so. On a whim, and after reviewing the lack of progress while I have been preoccupied with school, I decided to message you and see if you have any correlation with the ARG.

I refuse to give up until I see this thing put to bed, and I’ll pursue all venues and investigate as much as possible while I have time this summer in an attempt to see it through.

You’ve been a stellar help in the past, and I only hope you can continue to be.

~Gun"

“Hey, sorry I’ve been super busy with things recently. I don’t have a huge amount of time, but I’ll look into it. I’ve got a few too many things on my plate at the moment, what with a new project I’ve just been put in charge of at work, but I’ll see if i can analyse this code somewhat and work out what it’s likely to be.”

Take your time, man. Been a bit busy myself lately, so completely understand where you’re coming from.

Hope all is well, and I look forward to hearing from you.

~Gun

The message after that last was the message that I shared with you all. Now, I mentioned to Code_ after the SECOM solution that I wasn’t sure how we was so keen on specific details, but that I would not blow any whistles and would consider him another bystander–like the rest of us. It was not until Storm posted the “seek out Code_” message, and after another long bout of no success, that I explicitly asked him. He never mentioned my inquiry, but his response, as you’ve all seen, was still extremely helpful. Other users had mentioned similar thoughts, but it never went anywhere beyond speculation. Once the forum finally found out for sure that 0418 was actually “Dr. Horn”, I figured that the messages were worth sharing.

The point behind my rambling is that Storm knew that I was onto him before his last message to me, but he still provided the examination you see in the long message. Therefore, analyzing it further, as flavrans9 has done, isn’t necessarily a bad idea.

It’s entirely possible that something further is hidden within.

The original PM’s are here

EDIT: Something bugs me about this part of the message:

"I ran the code through a few programs that analyze entropy via auto-correlation, the n gram results indicate a weak encryption, but one that results in highly entropic data (which I correlated against a similar data set size from a randomness extractor) when decoded via Hex, which I suspect is a secondary encode, as most encrypted data sent via communications is encoded in order to avoid corruption. This may have skewed the block size analysis done previously (resulting in 376bytes or 64bits)."

Wait, wait, wait. He says right here that he suspects the hex encoding was a secondary encode, which would mean we’re not meant to look at the actual hex portion of it, but the decrypted portion. In the original message, he even refers to the hex-decoded portion as the “code”:

"Code:
³+�:5ºÝfW|$ÁOÉCFÑ1§ÅK¸/þà"aWw?$y#Ü!ö,Ô.‘ògµE«Êí¯aQ
Nê‡Í3ÇÇ?q10œÄ(´$=TðDùÏb–Ù¿÷9~C˜æ2Ú
?äx³¥O]Üiuú÷I„žbYZŸc•‘=à>:¬?8ŒEû…þ‘5AÖÀƒ˜òȃ2¨/ß�(büÜOçäj?éQÅÈ´dã:¹,–†.‹À™¸8�Úy¶?ä¢Y›mHǹSŒîc‘D ôaº’äþu$,Ø?QÖ•Q˜‡j|ª½{@I"A0©f̳Á9F:?~š7ª†?²xü—1À œŒy~y“
@eF²Lšb›&Â?Î*KäXš7_ësÄ«"\„Œøž)²q3—6G?J‰(í֏TiŒ^[PgFövZo%Þ¤Ú@þ¶e?E$i6•ˆ=Ë!æûþû¸Z)‘”€6¥+]"

This code is only 335 characters, a far cry from our 376-byte hex equivalent. As he said in that quote, the hex encode was probably a secondary method simply to reduce corruption, which thereby skewed the block size analysis. Couldn’t we, theoretically, break this into chunks or rework it to create an entirely different hex code(s)?

If the hex code is what we are supposed to be looking at, I have some further thoughts regarding decryption. I know everyone is hung up on AES encryption methods, but is it possible we could be dealing with 3DES? This would utilize up to three different 56-bit (7 character) keys, and we have quite a few of those available. Not to mention we have been seeing many references to the number 7. Just off the top of my head, here are some possible keys: BENALOH, NIOBIUM, HALOSAI (the AI part was bold on the Tempus page), and I’m sure we could find many others.

EDIT 2: I ran a 3DES decryption on the hex code with “HALOSai” as the key, and ended up with this:

"R{Wßgf��LzU0mi�M�ӣ �+PM?=R:����.���E��6�v �j�9�@dye{6P���’�ޱ��
ovS�L�������kt�� �QA"h�_+��%z�ze��K�="�1k��U���V:{9�A��6ښ�T���R]�helus��V50��v��?i��<
~+�7�G�� 1H�g���샮��$i���±�5�;�mA�O,�RRU��4A��
�O �2U�A���ʽ��d�I�0!O#d\�~�%͐�f#�)��&_|<������U�z%��s�x� ʖ���e;�}��s㈺d����t�ވC���$���"

It’s not very much to go on, and it could be a fluke, but the “dye” and “helus” caught my attention. Is it even possible to get a partial result without the full key implemented?

Also, IRC Clue 6’s capitalization has to come in somewhere, seeing as how the key input is contingent upon capitalization:

[[ProxyhoSt@-84-9-I23-345.dslgb.com//closed.proxy.accepTEd//?OTR,3,4,?OTR:[INCOMING TRANSMISSION]ThEpIzZaIsaLiE…HALOS[Transmission Ends]]

EDIT 3: As a final note before (probably) cashing in for the night, I’ve added a Cryptographic Functions table to the wiki to make it easier to see what the size of keys and IV’s are for various functions: Cryptographic Functions

When I decrypt the hex code (b32b003a35ba etc), select 3DES, HALOSai as the key and ECB mode I get a different result than you do. Why the difference?

ÙðüˆOp(öÏh.bN1íÍ˽mäöÑdÏýU…uÙÑ…v.z+¾ÛaæB.O+ØìÄ…£.yÙqmL¸°ÜtÍ·ó¦.ӖAÆ.Ýì0……1R.+òæd.L.D¼GWˆ,*.bzÐ.-»êc ].U.Ý.Ó"O1Ý.ͪ?pöˆ¿.õ«HøGz.‘9._.hýÉõԜ..{.L.4ùñ¡ß.HîõW.ôÖá>Y¶XÄ÷ÒMÝ.ÑÛõ,PÙç".·dH….ø©.6,T\4¼.=ðs...Ù.¡¹.õq1üÊ.R&Hb¼üB^óýf.Ô.|z(.Ó¨2î5XE[(.(&PÔ.è..o.v.é.ΰa&ù.{¬¹...ã@.Ô:..ô.$.á.^Ë>..ØØÐ÷U'7y$S®.rºÕ=Ó.1.=ÌpZg[.ÛïÐI]DD/b.ýC*K[/.T#.§.ÿOcÈØ...Ç.üeª¤üÚ^..4çê[VBh{¯d´

Well, I don’t really have any specific tools that I know work–I have to rely on online decryption tools. That was done utilizing this one: Code Beautify

It’s possible it doesn’t really work. I meant to ask about that, actually–I know faed was working on some open ssl decrypters, and I was wondering if anyone would be willing to provide some more information on how those work, or provide an online one that is verified. It’s frustrating not knowing whether or not the tool you’re using really works.

I must be doing something different than you. When I go to Code Beautify and select Tripledes, then try each of the different ‘modes’ and input HALOSai as the keyword I still get something different than you do. Are you using the hex code (b32b003a35badd66577c24c14fc919064346d131a7c54bb82ffe03…) as the string to decrypt?

Hmmm . . . I’m not sure what’s going on. Here is a screenshot of my result when I do it:

[attach=3557,none,840][/attach]

That site expects base64 encoded data for decryption, not hex.

Yeah, that’s the key problem with these damn online tools. Do you have anything you might recommend, faed? I recall in the earlier stages of the hex code that you were providing some open ssl decryption methods–any chance you have kept up with them?

Here’s halos in B64

sysAOjW63WZXfCTBT8kZBkNG0TGnxUu4L/4D4CJhV3ckeSPcIfYs1BgukcOyZ7VFq8rtrwJhUQ1O6h6HzTPHx3ExMJzEKA60JD0RVPBE+c9iltm/9zl+Q5CYf+YyA9oN5AJ4s6VPXdxpdfoE90mEnhpiWVqfYwsHlZE94BU+Oqw4jEX7nYUM/pE1QdbAg5jyyIMyqC/f...==

As far as encryption tools beyond OpenSSL (since Storm specifically said he did not use their implementation), Cryptool 2 is a good suite for this stuff.

https://www.cryptool.org/en/download-ct2-en

Thanks, man! Y’know, even though I’ve spent the last few years learning about different ciphers and can spout them off like the alphabet, there are still so many intricacies that I don’t fully understand yet. As you can see from this case, I’m fine digging for clues and applying different methods to the hex code, but I’m forced to utilize tools that have already been created. In that sense, I am completely out of my league. Of course, the ARG isn’t meant to be easy, so I’m definitely not complaining. It’s simply frustrating thinking that I can’t make the same connections to the ARG clues as someone with cryptography implementation experience.

AWESOME! Thanks!

I see what I did to get a different result. I inputted the code in a string instead of breaking it down in 8 character components.

Is that not the right way to do things though? The code was originally found as a singular string after all.

For online based:

AsciiToHex: https://www.asciitohex.com/ - Simple conversion tool, doesn’t actually encrypt or decypt, but simply converts a variety of encodings to ascii (as well as others). Useful for Base64, unencrypted hex, decimal, binary, and Rot13.

Tools4Noobs: https://www.tools4noobs.com/online_tools/decrypt/ - Supports multiple Rjindael’s, TwoFish, BlowFish, DES, Serpent, and supports Base64 and Hex input.

online-domain-tools: https://aes.online-domain-tools.com/ - I tried decypting the 752 with this for a while, it works pretty well. 3DES, DES, BlowFish, TwoFish, Serpent, Rjindael 256. It supports hex and plain text input.

For software based cyptographic:

Obviously OpenSSL, but without the GUI it’s difficult to use. https://www.openssl.org/related/binaries.html

CrypTool2 (Windows only): https://www.cryptool.org/en/cryptool2-en - Supports DES, 3DES, AES, TwoFish (and several others that are not currently important), and has tools for Steganography.

JcrypTool (Linux, Mac, Windows): https://www.cryptool.org/en/jcryptool-en - Doesn’t support DES, 3DES, TwoFish. It is much more limited, but is under major development. It’s major benefits are fantastic analytic tools, and is being update regularly.

Other than those two, I haven’t found any other software based cryptographic tools.

Astij: Yes, and that’s something that I will rectify in my forthcoming attempts. I didn’t realize that the spaces would prompt different results, but apparently they do (at least in the case of that tool).

DeathTBO: Thanks for this. I feel good knowing that folks like you, faed, flavrans9, CPU and others are a part of this. TOGETHER, WE CAN SOLVE THIS.

EDIT: BTW, this CrypTool2 is goddamned fantastic. Where has it been all this time???

I am truly impressed by this. I can set it up so I’m running multiple decryption attacks at once, whilst simply changing the key and looking for solid results. Man, I can’t believe how hard I’ve made it on myself these past years.

Isn’t it possible that ‘seek code out’ means that HALOS is transmitted using a coding, error detection coding in particular(Hamming codes for example).
As HALOS/752 hex code is some sort of transmission, which is prone to bit errors, it might be possible that error detection/correction codes were applied.
Just a random thought I had.

I looked into the differences between the hex code and the version from Code_'s PM. There seems to be a few inserted hex values–the most common of which was “3F”–but what’s more interesting is the omission of some 120 hex characters (60 bytes) from the original hex code.

The omissions always occured in pairs–that is, as full hex encoded bytes.

I have no idea what it means. It might have been done intentionally, or it might have occured by mistake. I’ll keep looking into this.

I think that’s just because the conversion from hex to the ASCII version results in the loss of some bits. I converted the original hex code to ASCII and received the same output as Code_'s in the PM.

has anyone noticed the possibly coincidental “Helus” in the second line. This possibly puts my theory in motion that some of the code is switched around, much like the CIA Crpytos Statue

I know that “Aren’t you alone” is linking to Nihilanth god damn it, I’m not stupid.

No need to sound like a dick…

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.