Multilayer Image Steganography

Question

Alice, Bob, Carol, and Dan are playing a card game. After they all show their cards, Bob notes that by exchanging two cards the order of the players would be reversed; that is, the player with the best hand would have the worst hand, and vice versa. Which pair of cards is he thinking of?

---

Since this puzzle is far too easy on its own, I've hidden the four players' cards in this image. I will only give you one hint, so listen up:

In order to complete this challenge, you must verify every step.

^{Download as png (1 477 855 bytes) | tiff (1 512 448 bytes) | bmp (1 513 654 bytes) | ppm (1 512 102 bytes)}

Answer 1

The final answer is:

The current status is:
South (Flush) > North (Three Aces) > West (Aces and Twos) > East (Two Aces).

Swap the 5 of hearts in West's with the Ace of clubs in the board.

The new status is:
East (Straight) > West (Aces and Twos) > North (Two Aces) > South (Ace high)

The clue "listen" pertains to audio files embedded in the images.

The legend for the blue layer is four cards. The file is an OGG Opus file. The audio is someone saying "If you haven't found any clues yet, here's what you should be looking for" followed by what sounds like a dial up modem (yes I'm that old).

The blue layer contains an SSTV image. I was able to display he image using RX-SSTV but not having speakers headphones don't put out enough volume to make the image clear. It is definitely the picture of the poker game but I can't make out the cards clearly.

The red layer contains the key. It appears to be OGG Opus file http://en.wikipedia.org/wiki/Opus_(audio_format) but I can't play it here. See Quark's Answer for the decryption.

The green layers contains three pieces of information according to the legend.

The green values as noted in the colour histogram by Tryth correspond to the ascii values of letters (except for 0 and 255 of course). I don't have the space to upload the whole text file, but here are the first few lines:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.12 (GNU/Linux)

hIwDAAAAAAAAAAABBACSYQ99ag0VMUFXZqrBGDRem4eEilmls/7ZvvGAzZqfMsmE
NjX+WuH5gKyVVI1TGECpVxQq8jkFgdmSHxaW3+CPlVp5KbYrOAy39503BXwWQUQC
bmQaM9CKNvcJGwJwO6EP+H3h5YaRmlPLntVnwkyZltODbMRsyCd41RExlRGxhNL/
AAWDQQEUxtxTEahwiwqL0vID7XUVfqEovUk+aho0FPUuSuqU94l/hrh8rTSglQTd
x/1izqHZI0YG4Nir9sy6amtDNpafDN/IQCD8r3qp/gw2bvpKg4v9Df27frSju7Xr
...

The whole PGP stream will be in the greengs.ppm file when this C code is run with img.ppm in the execution folder:

#include <cstdio>
#include <cstdlib>
using namespace std;

int red[256],green[256],blue[256];

int main() {
    unsigned char * buffer;
    FILE *fin = fopen("img.ppm", "r");
    FILE *fout = fopen("imgverify.ppm", "wb");
    FILE *fred = fopen("red.ppm", "wb");
    FILE *fgreen = fopen("green.ppm", "wb");
    FILE *fblue = fopen("blue.ppm", "wb");
    FILE *fredgs = fopen("redgs.ppm", "wb");
    FILE *fbluegs = fopen("bluegs.ppm", "wb");
    FILE *fgreengs = fopen("greengs.ppm", "wb");

    // Input the data from the ppm file into the buffer
    int lSize;
    fseek(fin, 0, SEEK_END);
    lSize = ftell(fin);
    printf("%d\n", (lSize-15)/3);
    rewind(fin);
    buffer = (unsigned char*) malloc (sizeof(unsigned char)*lSize);
    size_t result = fread (buffer,1,lSize,fin);

    for(int i = 0; i < 15; i++) {
        fprintf(fout,"%c", buffer[i]);
        fprintf(fred,"%c", buffer[i]);
        fprintf(fblue,"%c", buffer[i]);
        fprintf(fgreen,"%c", buffer[i]);
    }

    buffer[1] = '5';
    for(int i = 0; i < 15; i++) {
        fprintf(fredgs,"%c", buffer[i]);
        fprintf(fbluegs,"%c", buffer[i]);
        fprintf(fgreengs,"%c", buffer[i]);
    }


    for(int i = 0, x = 15; i < 785; i++)
        for(int j = 0; j < 630; j++, x += 3) {
            printf("(%d,%d) = (%u %u %u)\n", i, j, buffer[x],buffer[x+1],buffer[x+2]);
            fprintf(fout,"%c%c%c",buffer[x],buffer[x+1],buffer[x+2]);
            fprintf(fred,"%c%c%c",buffer[x],0,0);
            fprintf(fgreen,"%c%c%c",0,buffer[x+1],0);
            fprintf(fblue,"%c%c%c",0,0,buffer[x+2]);
            fprintf(fredgs,"%c",buffer[x]);
            fprintf(fbluegs,"%c",buffer[x+2]);
            fprintf(fgreengs,"%c",buffer[x+1]);

            red[buffer[x]]++;
            green[buffer[x+1]]++;
            blue[buffer[x+2]]++;
        }

    for(int i = 0; i < 256; i++)
        if(green[i])
            printf("%d %d\n", i, green[i]);

    fclose(fin);
    fclose(fout);
    fclose(fred);
    fclose(fblue);
    fclose(fgreen);
    fclose(fredgs);
    fclose(fbluegs);
    fclose(fgreengs);
}

The first clue in the green layer is a lock. That refers to the PGP Encrypted Message. Decrypting it yields the following message:

The second clue is that it needs to be verified. Importing the public key for the fingerprint 0x40842FD6 and decrypting again yields some more interesting information:

We can extract that image using the following options:

gpg --list-options show-photos --fingerprint 0x40842FD6

This yields this final image:

The third part of the green legend is the decrypted file containing the three cat image shells (the hollow squares) and the three card images.

Answer 2

This answer follows from the previously found red and blue frequency audio files and the green frequency PGP message.

The red audio file starts out with a morse code sequence, followed by three voiced words (surrounded by high pitch noises) and what I assume to be DTMF tones. After spending more time than I care to admit doing it manually (because of my confidence in my morse coding skills), I did it like a sane person and analyzed the audio waveform. Here is what they decode to after triple checking both:

...- ...- ...- -.-. .-.. --. .--. ..- --.. -.-. .-.. --. .--. ..- --.. -.. . .-. -... -.-. -...- --. .- ...- -.-- ..-. -... ... ..-. .-. -...- .. ..-. ..- -.-. -. - -- .- -.- . -.- . -.-- ... .. --. -. - .. ---.. ...-- .--. ..- -... -.- . -.-- . ... .--. --- ... - ... .. --. --..-- .. .-- .-.. .--. --- ... - -.- . -.-- -...- ..- ... . .--. -.- -.-. ... .---- -. .--. .- -.. -.. .. -. --. -...- --... ...-- . ... --. .-.. .--. ..- --.. -.. . .-. -... -.-. -...-.-

VVV CLG PUZ CLG PUZ DE RBC = GA VY FB SFR = IF U CNT MAKE KEY SIGN TI83 PUB KEY ES POST SIG, I WL POST KEY = USE PKCS1 N PADDING = 73 ES GL PUZ DE RBC

Translation:
testing(compare morse code for V to Beethoven's 5th) calling (PUZ) calling (PUZ) of (RBC). Good afternoon very fine business so far. If you can't make key sign TI83 public key and post signature, I will post key. Use PKCS1, no padding. Best regards and good luck (PUZ) of (RBC).

No idea what PUZ and RBC are but they seem to be referring to the solver.

(beep) echo papa quebec (beep)

65537#10279922920444758952198236835097069960343622366001203286574422344156143529924117113239897731294792673018741448270384194591460111562322538604975737399705241*11337130627295915340299728600099026395063941250029823456400750546429518737269225761911696211987509755865509636756944318366919520522935654742514845464086299

This is probably to build an RSA key for the PGP message, where the public exponent is 65537 and the two primes are
c447376fcf2a4d4f03840c83f68b23202f081f8561a1f0295703df258a96b8fd6cc8cb307558d60cbd692a45ed2414370349e28badf0f180419fc1df2cd87e99
and
d876bd7c4963b8c06f148da504d1f7c7b9b20a719a0d3788eacc7effa7acb9cc200ef3a18a29fb5c733d45e04104ef3e7fc77f3ec847526b0c5d50506a2f471b
(converted the two numbers to hex).
The value of two primes multiplied is
a5f720e1c30658d4edb092a81197401b7a7f2c6224ef6411b8df246ccc4926eeed4abb756dcd294b68b59e7824e6bf46917c1354ad050f0de0beeb61b7537d834bf21315e1e4b15c3e84715e1ecca06fddf88a7d139aac22c479685b839b46f8464ce766dbe8fe4e65a4c6b6e72bfac8f6b2dd90ab44ed9f0ff597f45e08c923.

For the blue frequency audio:

The sound of the blue frequency audio contains an SSTV image (figured out by LeppyR64). This image can be decoded by software (see here), and when decoded, the following image is created.


The cards seem to be:
North: Ace of diamonds and either a spades or clubs.
West: Two and Five of Hearts.
South: 10 and 4 of clubs.
East: 4 of hearts and possibly 2 of diamonds.
Table cards: 9 of spades, 7 of clubs, 2 of clubs, ace of hearts and ace of clubs.

North has 3 Aces 9 high, West has two pair of Twos and Aces 9 high, East has two pair of Twos and Aces 9 high, and South has a flush Ace high. If North exchanges an Ace with the 7 of clubs, that ruins South's flush and gives East and West a full house. (Answer subject to change upon decoding the image clearer)

For the green frequency:

Jarnbjo decrypted the PGP message into three cat pictures. The third (porsche.png) includes two different .png images, and by using notepad++ to delete the top half, this is the resulting image (East cards):


For Allie.jpg, an image can be extracted by deleting the first half of the JPEG header (~half way through the first line, everything before the second ÿØÿà). The image is below and shows the West cards.


For bitsy.tiff, there is an embedded thumbnail, so the image showing in the file explorer is different from the actual image. The TIFF image is a container for two JPEG (credit: Jarnbjo), by deleting the above image and the TIFF container, you can extract a quality thumbnail image(the North cards, below).

Edit 1: Fixed morse code spacing and added missing numbers.

Edit 2: Added blue frequency interpretation and more to red frequency.

Edit 3: Fixed "epq" hint.

Edit 4: Added card table (may be possible to decode clearer).

Edit 5: Added porsche.png hidden picture.

Edit 6: Added allie.jpg hidden picture.

Edit 7: Added bitsy.tiff hidden picture.

Edit 8: Added better method for getting allie.jpg hidden picture.

Answer 3

Decrypting the PGP file from the green channel using the DTMF encoded RSA key from the red channel results in a BZ2 compressed TAR file containing the following three images:

• allie.jpeg
• bitsy.tiff
• porsche.png

Decrypting the PGP message can be done with the following Java class (BouncyCastle libraries must be included in the project):

• Decrypt.java

Quark already pointed it out, but the full resolution thumbnail contained in the bitsy.tiff image can be found here:

• bitsy-tn.jpg

Quark already added the image to his answer, but for some reason he only added a much smaller and difficult to read version (a thumbnail of the thumbnail :-)

LeppyR64 asked for the raw decrypted data, so here we go. Using the Bouncy Castle PGP API, I get the following raw output:

• green.dat

I used the documentation in RFC 4880 to decode the message header manually:

• AE - literal data packet, packet length encoded with 4 bytes
• 00 05 83 13 - 361235 bytes packet length
• 62 - data packet contains binary data
• 10 - file name length: 16 bytes
• 70 69 63 74 75 72 65 73 2E 74 61 72 2E 62 7A 32 - file name: pictures.tar.bz2
• 55 60 CD BE - file modification date: Sat May 23 20:58:06 CEST 2015

After removing the PGP packet framing, the following file comes out:

• pictures.tar.bz2

Even if it has been found out which cards should be swapped, there are obviously more bits to this puzzle not yet solved. Perhaps my partial anaylis can help any of you further.

There are several clues mentioned, which have not yet been used. Since no obvious red herrings have been found yet, I still assume that the clues and data should make sense. Among the unused clues are references to the TI83 key, signatures and PKCS#1 padding. I am not sure why 2012rcampion writes that these clues and hints are not required anymore, since they were completely irrelevant when decrypting the PGP message. The green layer contains a proper PGP header, making it obvious that PGP encrypted data follows and then only the e, p and q parameters from the DTMF data was required for decrypting the PGP block.

The green channel does not only contain the PGP message, but also a few more bits and pieces of information:

Directly following the PGP message is about 5000 bytes of text. I am not sure if this is the signature, which is mentioned in hint 2, but I would assume not. The signature is probably part of the PGP message itself, but I can't find a way to extract it using the BouncyCastle API.

The text looks like base 64 encoded binary data, at least it only contains characters used by base 64 and has a very unconventional line feed pattern. The line length varies between 1 and 234 characters (reading 1234 is perhaps not a coincidence) and I assume that the line length must be considered somehow in the decoding process. Trying to decode the data directly as base 64 (ignoring the line feeds) gives 3705 bytes of seemingly random data. There is some variation in the histogram, but no obvious specific distribution. I have tried to decrypt the data both with the DTMF encoded RSA key and with the TI83 key, but had no success. 3705 bytes would also be way too much for a mere signature.

Following further is 9450 bytes only with values 0x00 and 0xff. Arranging the data properly gives a repeat of the image of the key and the four squares (red and blue part) in the legend.

Answer 4

This is a "canonical" answer meant to move the hints and partial results out of the question, as well as present a unified description of the solution and explain some of my thoughts about the puzzle.

Warning, unmarked spoilers ahead!

First Layer

Hieroglyphics

I called the symbols at the bottom of the initial image "hieroglyphics." Here they are, magnified:

Colors

The colors are supposed to hint that the image needs to be separated into its three color channels: red, green, and blue.

Red Key

The key indicates that the red channel holds a key used in another part of the puzzle.

Blue Boxes

The four hollow boxes represent four parts of an image encoded in this channel. The fact that they are hollow is supposed to indicate that this picture is not the 'real' solution.

Green Lock and Boxes

There are three groups of symbols here.

• The first, a lock, indicates that the green channel is encrypted, and needs the key from the red channel.
• The solid boxes are supposed to indicate the 'real' (high-resolution) pieces of the image from the blue channel.
  The check mark signifies verification. The solid box over the check is supposed to indicate that one part of the image is somehow part of the verification process.
• Finally, there are three pairs of hollow and solid boxes. These represent three cover images (hollow boxes) which each hide another part of the solution (solid boxes).

Most of the hints in the hieroglyphics were not necessary, so this part wasn't solved/explained in full. However, I'm glad I included it, since it reduced the number of extra hints necessary to zero; which, in my mind, is the mark of a good puzzle. (OK, this isn't totally true, but more on that later.)

Color Channels

Each one of the three color channels in the image encodes a different file.

To decode, you just need to take the 8-bit image values for each pixel and write them to a file. There are no extensions, but you can figure out the file types from their magic bytes using a utility like file. (Or just use a hex editor; the Ogg files begin with Ogg, and the encrypted file begins with -----BEGIN PGP MESSAGE-----.)

This part was solved by LeppyR64 .

Not all the files were the same length, so I had to pad out the two shorter ones. Fortunately none of the formats mind having extra junk appended to them. I padded the files using random bytes drawn from the same distribution as the rest of the file, so that there wasn't an apparent change in color or texture.

Second Layer

Blue Channel

The blue channel contains an audio file: blue.ogg (504 000 bytes)

This audio file contains a voice reading the sentence, "if you haven't found any clues yet, here's what you should be looking for." This is followed by an SSTV image of the playing cards mentioned in the question.

This part was also solved by Leppy64.

The intent was that this image should provide an overview of the four pieces that need to be found. However, I underestimated how well the image could be recovered, meaning that the puzzle can be solved without finding the four hidden pieces. If I were to do this again, I would have added extra noise to make identifying the cards impossible.

Red Channel

The red channel contains an audio file: red.ogg (504 000 bytes)

The audio file in the red channel contains morse code, which reads as follows:

VVV CLG PUZ CLG PUZ DE RBC = GA VY FB SFR = IF U CNT MAKE KEY SIGN TI83 PUB KEY ES POST SIG, I WL POST KEY = USE PKCS1 N PADDING = 73 ES GL PUZ DE RBC <BK>

I made heavy use of morse-code-specific abbreviations in order to shorten the message, making it a bit challenging to read. Here it is in plain English:

(VVV) [attention] Calling PUZ, calling PUZ, this is RBC. Good afternoon, very fine business [good job] so far. If you can't make the key, then sign the TI83 public key and post the signature, I will post the key. Use PKCS#1, but no padding. Best regards and good luck; PUZ, this is RBC, over.

This is followed by a long series of DTMF tones, encoding the following sequence:

65537#10279922920444758952198236835097069960343622366001203286574422344156143529924117113239897731294792673018741448270384194591460111562322538604975737399705241*11337130627295915340299728600099026395063941250029823456400750546429518737269225761911696211987509755865509636756944318366919520522935654742514845464086299

They are (in decimal) the public exponent $e$ and primes $p$ and $q$ of an RSA secret key. They are followed by my voice reading the words "Echo, Papa, Quebec" (EPQ in the NATO phonetic alphabet, identifying the three numbers), surrounded by Quindar tones (because I'm a huge geek).

The morse code describes an "alternate route" I put into the puzzle. It took me quite a bit of effort to obtain a PGP private key from the information above. I eventually resorted to using RFC 4880 (which describes the PGP message format) to create the key by hand in a hex editor:

-----BEGIN PGP PRIVATE KEY BLOCK-----

lQHaA1VfT04AAAEEAKX3IOHDBljU7bCSqBGXQBt6fyxiJO9kEbjfJGzMSSbu7Uq7dW3NKUtotZ54
JOa/RpF8E1StBQ8N4L7rYbdTfYNL8hMV4eSxXD6EcV4ezKBv3fiKfROarCLEeWhbg5tG+EZM52bb
6P5OZaTGtucr+sj2st2Qq0Ttnw/1l/ReCMkjABEBAAEAA/0QocRve3jeXBr5z/38d/jaXXCd2l6z
MtxnzMznWPhCaOfqI6vFS4MbkIHAQMVfQ8SRqH/TbjIMln/IV5Rc/TFIVsN/+6thU8ddbuQL6jeE
h+HMKiYmAtnXNfDfb3QVZikh4sYkrOBRws0zE9UVsAtobIppT1gE+INlfpSr6fmFsQIAxEc3b88q
TU8DhAyD9osjIC8IH4VhofApVwPfJYqWuP1syMswdVjWDL1pKkXtJBQ3A0nii63w8YBBn8HfLNh+
mQIA2Ha9fEljuMBvFI2lBNH3x7myCnGaDTeI6sx+/6esucwgDvOhiin7XHM9ReBBBO8+f8d/PshH
UmsMXVBQai9HGwH7BEv1GeXZ6yL4eKC4jBvcdqRM/tuiSZodqIZBSQ8BaQG7X6m1IEL5pH8EXhr7
LWcruhlYtSIMBREid82G/p0SPZ+StQA4U3RhY2sgRXhjaGFuZ2UgVXNlcnMgKGh0dHA6Ly9wdXp6
bGluZy5zdGFja2V4Y2hhbmdlLmNvbSk=
-----END PGP PRIVATE KEY BLOCK-----

However, Jarnbjo actually managed to construct the key in software using the Bouncy Castle crypto library, avoiding the need for the alternate route.

The "alternate route," was supposed to be for someone to use the provided key to sign a known piece of data. This requires the computation of $d$ (the private exponent), the number such that $e\times d \equiv 1 \bmod {\varphi(n)}$. The signature of a message $m$ is then just $c=m^d \bmod n$. These computations (modular inverse and modular exponentiation) are "easy" (computationally efficient) if $\varphi(n)$ is known. Given the factorization $n=p\times q$, then $\varphi(n)=(p-1)(q-1)$.

The plan was that if someone provided the value of $c$ by performing the above calculations (or equivalent)—proving that they understood what the key meant and how to use it—then I would provide the PGP key file I made.

However, there were some complications:

• I needed a (preferably large) message for the puzzle solvers to sign, and didn't have a lot of space left. So I chose the TI83's signing key's public modulus as a large, publicly-known number that is connected to cryptography.
• When GPG generates keys (and I generated this key with GPG) it actually computes $d$ as $e^{-1} \bmod {\operatorname{lcm}(p-1,q-1)}$, as recommended by the PKCS#1 standard. It's been a while, so I don't remember if GPG complained when I tried using the other definition of $d$ or if I just didn't know the two are interchangeable (they both have the property that $m^{e\times d}\equiv m\bmod n$), but I thought it was necessary to convey this information to the puzzle solvers.
• Finally, PKCS#1 also specifies padding and hashing algorithms used when computing signatures, which I didn't want the puzzle solvers to have to use if they wanted to go the alternate route, so I specified "no padding" in the puzzle.

Overall the "alternate route" was a pretty bad idea, and one of the two major flaws in this puzzle. This clue was very confusing (particularly my use of morse abbreviations) and ultimately unnecessary.

As for why I included it: this was the first puzzle I had posted, so I didn't yet have a good idea of the interaction between the puzzle maker and puzzle solvers (namely that the puzzle solvers would say if they were having trouble and needed a hint). I was also possessed by an extreme desire to make the puzzle totally-self contained with no "extra" hints whatsoever.

Also, I probably should have gotten someone with better enunciation to do the reading in this puzzle. =)

Green Channel

• The green channel contains a base-64 encoded OpenPGP stream: green.gpg.asc (491 216 bytes)

As I mentioned before, jarnbjo successfully decrypted the green channel's PGP stream using the private key values listed above. If you want to do this yourself without installing the JDK or Bouncy Castle library, you can use the PGP key above with GnuPG.

Third Layer

Decryption of the PGP stream results in a compressed directory (green.tar.bz2 (361 213 bytes)). It contains pictures of my three cats (because, why not?) in three different formats. Each hides one quadrant of the image of playing cards. Each also contains a comment which is a hint as to how the playing cards are hidden.

allie.jpeg

^{download original (81 938 bytes)}

This image contains the comment:

The "middle child" of our cats, Allie is quite shy as well as a real pushover. This uses the same trick as the tiff image, but slightly harder.

The clue says that this one is harder, because it's more difficult to spot; but technically it's pretty simple. Quark found that if you delete the file's header and open the file, the lower-left quadrant of the playing card image is revealed:

This image is actually stored as an EXIF thumbnail. A quick side note: JPEG is not a file format, it is actually the name of a compression algorithm/image encoding. JPEG-encoded images are usually stored in a JIF (JPEG Interchange Format) file. In the language of video encoding, JPEG is the codec and JIF is the container—as an analogy, an AVI file (the container) might hold an H.264 video stream (the codec).

To make things even more complicated, there are two commonly used, mutually-incompatible, extensions of JIF: JFIF (JPEG File Interchange Format) and EXIF (EXchangeable Image File format). They both have the capability to store a thumbnail of an image, either uncompressed or as a complete, self-contained JPEG image.

In this case the thumbnail is stored (JPEG-compressed) in a JFIF container, which is itself the thumbnail of the outer EXIF container. Since the thumbnail is stored as a complete, self-contained JFIF image it can be viewed by moving it to the front of the file (or scanning the file with a tool like JPEGsnoop). I embedded the thumbnail with ExifTool, available with most Linux distributions.

bitsy.tiff

^{download original (141 085 bytes)}

This image contains the comment:

Bitsy, our oldest cat, is the heaviest of the three by far. I thought it fitting that she should get the most bloated format in this challenge.

Quark noticed that, in Windows Explorer, the thumbnail of this image is the upper-left quadrant of the playing card image. Jarnbjo found that by deleting the TIFF headers and image data, the remaining part of the file can be opened as a JPEG image:

^{download original (43 875 bytes)}

The TIFF (Tagged Image File Format) specification is a real monster to work with. It was originally designed to be a "universal" format to replace the raw formats used by various camera and scanner manufacturers. In practice, this meant that the specification had to encompass pretty much all of the commonly-used encoding methods—hence the joke that TIFF stood for "Thousands of Incompatible File Formats."

TIFF encodes an image's metadata as a list of tags called an Image File Directory (IFD) that describe an image. These tags usually contain small bits of information about the image (e.g. the resolution, color type, where the image data is located in the file, etc.) but they can also point to other IFDs describing other images. This facility is used to allow TIFFs to encode multi-page documents, or (in this case) to embed a thumbnail of the image.

Although TIFF is usually used to hold losslessly-compressed image data, JPEG compression is allowed in a "Baseline" TIFF (meaning that all TIFF readers are required by the standard to support it). However, when exporting as a lossy TIFF, GIMP (my photo editor of choice) didn't allow me to change the compression settings (so I couldn't get the image as small as I wanted). So, I used the huge flexibility of the TIFF format in the way it was intended: I put the two JPEG files (actually JFIF files, remember?) together, and then appended a hand-written TIFF header constructed to point into the data sections of each JPEG. This has the added "benefit" that the two images are each complete, self-contained JPEG files that you can examine and extract (optionally with a tool like JPEGsnoop).

porsche.png

^{download original (137 079 bytes)}

Quark found that by deleting the first half of the image, the upper-right quadrant of the playing card image is revealed.

Nothing too clever here. The hidden image is also a PNG, and it is simply appended to the main image. The main challenge was getting the filesize small enough while retaining detail. You can see some pretty heavy banding and speckling in the cover image.

There was supposed to be a comment on this image too, but I apparently forgot to add it. The original copy of the embedded image has the comment "Told you it was pretty dirty..." (but it looks like this comment went missing in the final version?), so it was probably something along the lines of "Porsche, our youngest cat, is a real trickster. So, this image is hidden with a dirty trick." It was almost exactly a year ago when I made this puzzle, so I don't quite remember.

Second-and-a-half Layer

The third layer yielded only three of the four pieces of the playing card image. To find the fourth, we have to go all the way back to the heiroglyphics:

The check mark signifies verification. The solid box over the check is supposed to indicate that one part of the image is somehow part of the verification process.

Indeed, if we check the encrypted file from the green layer, we find that the file is signed as well as encrypted. In order to verify the signature you need the public key of the signer, in this case me. But where can we get my key? From a public keyserver, of course! If you download the key I made for this puzzle, you will find that it has an attached image! LeppyR64 extracted this image to reveal the fourth quadrant of the playing card image:

I don't really want to talk about this part. This was supposed to be the pièce de résistance, the most clever of clever parts of the puzzle. However, the original version of the puzzle omitted the signature on the encrypted file, causing much frustration on the parts of the puzzle-solvers, and much wailing and gnashing of teeth on my part when I discovered my mistake.

---

Here's what I think happened. I work mainly on a Windows desktop, but for programming and other tasks I prefer Linux, so I run a Linux virtual machine (VM) in Windows. Parts of this puzzle (e.g. the encryption tasks) were performed on the Linux VM, and parts (e.g. the image manipulations) were performed on the Windows host. Due to some poor planning, I essentially had two copies of the project that I manually synchronized, one on Linux and one on Windows.

When I had all the parts of the puzzle finished, I decided that it would be best to test them on a computer without the original files, so that I could be sure that it was possible to do every step of the puzzle. I also have a Windows laptop, which is in the same situation (Windows host, Linux VM), that I used to "verify" the puzzle. When I copied over the project to that computer, I now had four (independent!) copies of the project floating around.

At this point I found and corrected a few mistakes, so I modified the 'final' files and moved them back to my desktop to upload them. At this point some files got shuffled around, and an intermediate file (the encrypted but unsigned copy of the "green" file) got substituted for the final (signed) one. I incorporated and uploaded the wrong file, and the rest is history.

Now my VMs are configured to share the same filesystem as the hosts, and my two computers are synchronized through the cloud.

Fourth Layer

Assembling the four quadrants obtained from the previous parts, we get the full layout of the poker game:

(click for original)

The cards in play are:

• Community cards: 9♠ 7♣ 2♣ A♥ A♣

• South: 10♣ 4♣ — flush (in clubs)

• North: A♦ 3♠ — three-of-a-kind (aces)

• West: 5♥ 2♥ — two pair (aces and twos)

• East: 4♥ 3♥ — one pair (aces)

South's flush depends on all three clubs in the community: removing any one of them will greatly devalue his hand. Similarly, North and West both use the aces (including the ace of clubs) in either a pair or three-of-a-kind. From this we can guess that the ace of clubs is a key card.

The solution comes when we notice that East is close to a straight: he is just missing a five. If we swap the only five in play (the five of hearts in West's hand) with the previously-identified ace of clubs, we get:

• Community cards: 9♠ 7♣ 2♣ A♥ 5♥

• South: 10♣ 4♣ — nothing (ace high)

• North: A♦ 3♠ — pair (aces)

• West: A♣ 2♥ — two pair (aces and twos)

• East: 4♥ 3♥ — straight (five-high)

Thus reversing the ranking of the players' hands.

This part was solved by LeppyR64.

I'm not sure where I got the idea for this part of the puzzle from. I always knew that I wanted and endpoint a little more substantial than "you did it!" Poker worked well since the setup can be conveyed visually, and in separate pieces. The distinctiveness of playing cards was sort of a benefit, since I could get away with using very low-resolution images in some cases and the card values were still legible; however this was also a problem, since they were even legible in the "overview" image! Overall though I was satisfied with the poker puzzle.

This puzzle wasn't very hard to solve, but it was a little difficult to come up with. Once I came up with the idea, I just wrote a program to find the puzzle scenario by brute-force, testing random hands until one matching a specific description (existence of a unique swap that reverses the rankings of the players) was found. I left it running overnight, and it found two solutions. The other didn't have as many "types" of hands (three of the players had straights!) so I rejected it, using the one you see.

---

Please let me know if I misattributed any parts of the solution, and comment if you have any more questions about the creation of this puzzle!