Silicon Valley Encryption, Part I

Posted on by

I’m a fan of the HBO Series, Silicon Valley. From creator Mike Judge, it excellently showcases the antics of the nerds who populate California’s Silicon Valley and the companies they work for. It’s a brilliant series that I highly recommend to my techy friends. Plus, it’s chock full of digitally delightful easter eggs.

The show centers around a group of programmers working in an incubator. One of them, Richard, stumbles upon a compression algorithm that is magnitudes greater than anything else. This “Pied Piper” algorithm is the catalyst that runs the show and motivates the many adventures and missteps that take place, lampooning a lot of Silicon Valley culture.

At one point, Richard quits the company he founded, leaving the other programmers to try to figure out his algorithm. An easter egg is found in a screenshot the code, shown in Figure 1. Fellow programmers are trying to decipher what Richard has done. One of them, Dinesh, points to an undocumented number in the code and says, “What is this number?”

Figure 1. Dinesh (Kamail Nanjiani) is frustrated by Richard’s poorly-documented and obfuscated Pied Piper code. (Silicon Valley, HBO)

The number shown in the code is an easter egg. The code is C, all visible in the image. When compiled, it outputs the string DREAM_ON_ASSHOLES, which is appropriate for one programmer to say to others who try to decode what was done. Here is the code:

2025_04_12-Lesson.c

#include <stdio.h>
#include <stdlib.h>

typedef unsigned long u64;

/* Start here */
typedef void enc_cfg_t;
typedef int enc_cfg2_t;
typedef __int128_t dcf_t;

enc_cfg_t _ctx_iface(dcf_t s, enc_cfg2_t i){
    int c = (((s & ((dcf_t)0x1FULL << i * 5)) >> i * 5 ) + 65);
    printf("%c",c); }
    enc_cfg2_t main() {
    for (int i=0; i<17; i++){
        _ctx_iface(0x79481E6BBCC01223 + ((dcf_t)0x1222DC << 64), i);
    }
}
/* End here */

The remainder of the code from the screenshot isn’t pertinent to the program. It might be another easter egg, but I concentrated on the code shown above.

Overall, the code is deliberately cryptic. It uses typedef statements to obscure the standard data types void and int. The indentation and formatting isn’t consistent, which makes it even more opaque.

Buried in there is the main() function. It loops, calling the _ctx_iface() function 17 times, once for each digit in the value 0x79481E6BBCC01223. This is the number Dinesh references in Figure 1.

What the code does is to decrypt the value 0x79481E6BBCC01223, which results in single characters output, forming the string DREAM_ON_ASSHOLES, which is funny if you watch the show.

It’s odd to me that the main() function fails to return a value, which doesn’t trigger any warnings, at least when built by using the clang compiler.

In next week’s Lesson, I un-obfuscate the code and comment upon it further.

5 thoughts on “Silicon Valley Encryption, Part I”

  1. I don’t know anything about this Pied Piper algorithm but there’s an interesting story about a man, I think he was Dutch, who “invented” a device which resembled a VCR (or old style large DVD player) on which he claimed was stored the equivalent of hundreds or thousands of VHS tapes or DVDs, compressed down to a handful of bytes each. He would never tell anyone how it worked and of course it didn’t work the way he claimed. It’s assumed he had a few movies on a HDD inside this device just to demo it. Anyone who knows even a bit about Claude Shannon and Information Theory will realise what he claimed was impossible.

    I just Googled 0x79481E6BBCC01223 and the second result is this article which was posted just 6 hours ago! You should have made this one of your monthly exercises.

  2. I swear, all the ideas, stories, and matching code snippets you come up with every week is quite impressive. That, I guess, is to say that I like this weeks entry ☺

    The only thing that bothers me is the unnecessary use of the __int128_t data type—while supported by GCC and Clang, it is non-standard and not at all supported by all compilers. I think the following variant of the code, although still obfuscated, is better:

    #include <stdio.h>
    #include <stdlib.h>

    typedef unsigned long long u64;

    /* Start here */
    typedef void enc_cfg_t;
    typedef int enc_cfg2_t;
    typedef /*__int128_t*/ long long dcf_t;

    enc_cfg_t _ctx_iface (dcf_t s, enc_cfg2_t i)
    {
      int c = (((s & ((dcf_t)0x1FULL << i*5)) >> i*5) + 65);
      printf ("%c", c);
    }

    enc_cfg2_t main (void)
    { int i;

      for (i=0; i < 17; i++)
      {
      /*_ctx_iface (0x79481E6BBCC01223 + ((dcf_t)0x1222DC << 64), i);*/
        _ctx_iface (i < 12? 0x9481E6BBCC01223 : 0x1222DC7, i % 12);
      }

      fputc ('\n', stdout);
    }

    Also this bit-shift thingy is all too complicated, could have been written with a single right-shift… but I guess thatʼs the point 😉

    Anyway, seeing how much I loved Mike Judgeʼs “Idiocracy” I guess I will have to give this TV show a try!

  3. Thanks. I’d love to contact the coder who came up with this gem. More to come over the next two weeks.

  5. I donʼt think the encoding chosen by one of the people involved with the “Silicon Valley” TV series, that has been the topic on this blog for the last 3 weeks, is particularly difficult.

    After all, the basic idea can be summarized as follows:

    * If string characters that are to be encoded are limited to those in the (ASCII) range of 65 to 96, then every single character (in that range) can be encoded using only 5 bits
    * If an integer variable is used, this means that the 5-bit value ‘message[0]-65’ could be stored in the bits 0–4 of such an integer variable, (message[1]-65) in bits 5–9, …, and in general, ‘message[i]-65’ could be stored in the bits (5·i)–(5·(i+1)-1).

    Using this scheme, a total of 12 characters could be encoded into a 64-bit int64_t integer variable (with 4 unused bits remaining).

    If we donʼt care about standards-compliance that much, we could even use GCCʼs compiler-specific __int128 integer type and encode a total of 25 characters, with 3 unused bits remaining (25*5 = 125 bits).

    Thatʼs the route the creatorʼs of this show went for the episode in question:

    1222DC₁₆|79481E6BBCC01223₁₆ =
    10010:00100:01011:01110:0|
    0111:10010:10010:00000:11110:01101:01110:11110:01100:00000:00100:10001:00011

    With that in mind,

    79481E6BBCC01223₁₆ encodes 12 characters á 5 bit, as well as the (lower) 4 bits of the 13ᵗʰ character
    1222DC₁₆ stores bit 5 if the 13ᵗʰ character in its LSB, as well as another 4 characters á 5 bit.

    I have uploaded some code on GitHub which contains a __int128_t encode_message(…) function illustrating the whole process:

    user@debian:~$ gcc -std=c99 -o siliconvalley SiliconValley3.c
    user@debian:~$ ./Siliconvaley

    Enter up to 25 characters in the ASCII range 65…96:
    Dream_on_Assholes

    Contains 17 valid char in the range 0 ≤ (character-ʼAʼ) ≤ 31
    With 5 bits/character, a total of 85 bits will be required to encode them

    … lower 64-bits: 0x79481E6BBCC01223
    … upper 64-bits: 0x1222DC

    Decoded message:
    DREAM_ON_ASSHOLES

    On other (unrelated) thing: on January 5ᵗʰ, 2025 a developer named Ken Pizzini announced the release of version 1.08.1 of the Free Software Foundationʼs bc arbitrary-precision calculator.

    I have taken the liberty, of compiling this code for Windows… a pre-compiled 64-bit executable can be found here. (To function properly, this may require that the Microsoft Visual C++ Redistributable is installed on computers where this program is to be run.)

    I only mention this, because relying on ‘bc’ itʼs actually quite easy to work with large integers (ibase…input base, obase…output base, scale…number of fractional digits):

    user@debian:~$ bc -q

    scale=0
    obase=2; ibase=16
    79481E6BBCC01223
    111100101001000000111100110101110111100110000000001001000100011
    1222DC
    100100010001011011100
    ^D

    (A PDF as well HTML version of bcʼs man page can also be found under the given link.)

Leave a Reply