Congrats, mecirt! Looking forward to see the solution :)

I might need a weekend extension.

But, if you want to give the solution Friday, go ahead. I'll try solving it without looking at it.

Nah, I'll wait then ;-)

A little late to the party, but I solved it too.

For the moment: that's a very nice puzzle. I'll add a comment or two when you say Wishbone says it's ok to discuss.

Just in case you're waiting on me... I haven't had the time to try it again and I'm happy to just wait for the solution. I'll be interested to see what I was supposed to be doing...

I'll try and write some sort of cohesive solution post and get it posted later tonight.

*** HERE IS THE SOLUTION TO THE PUZZLE ***

Let's start with the riddle: The first step was to figure out that the alpha channel of the PNG image had data embedded in it, and how it was embedded. In this case, the data was encoded with 1 bit per pixel, subtracted from the normal alpha value. Since the image was otherwise wholly opaque, the alpha value of each pixel was 255 for 0-bits and 254 for 1-bits.

A bit of an issue arose here, because I was not aware that I had unintentionally encoded each byte in little-endian bit order. I used the .NET BitArray class to convert the bytes to bits and back again, not knowing that the methods the class uses for that also reverses the bit order. Because I used this both for encoding the data into the image, and extracting it from the image again, I never noticed that this was even happening until Alaric.us clued me in. This added an extra layer of complexity to the puzzle that I had not intended.

When extracting the data correctly from the PNG, the first 4 bytes were BC 1A 00 00, followed by a lot of C64 BASIC code as ASCII characters, and ending with a whole bunch of 00 bytes (the unused part of the alpha channel). The 00 bytes are obviously not important. The first 4 bytes we'll get back to.

The C64 code looks like this (most of the data lines have been omitted): ... (lots and lots of data lines) ... (lots and lots of data lines) The first 4 lines are simply code comments. I did not intend this puzzle to require intimate knowledge of C64 BASIC to solve, so I gave as much help up front as I could, to make executing the code as easy as possible.

Basically (pun unintended) what the code does is to draw a picture. It does this by alternating between setting the color of a location on the screen, and drawing a character to that same location, then moving on to the next location. The values of the colors and characters come from the data lines, and are arranged in such a way that adding the next data value to the current one gives the next color or character to be used. This was an (only partially successful) attempt to prevent people from solving the puzzle by analyzing the code rather than executing it.

Upon executing the code on a C64 (or an emulator), the attached image called noomega.png appears. This is an indicator that the user has not solved the first two lines of the riddle, and must do so in order to progress.

In order to get the No Omega image to display, I utilized the fact that in C64 BASIC, lines are numbered. As such, it does not matter which order lines are entered in, they will always be executed in the order they are numbered.

Looking at the middle quoted bit of the C64 code, you'll notice that the line numbers suddenly jump backwards. The data lines from 1110 to 2130 contain the data for the No Omega image. The data for the image containing the game code are in lines 2140 to 3040. The data is organized in such a way that the final data point of each section results in a value of 255, which causes the program to terminate. This means that even though the data for the real image is present in the code, it will never be executed because the program will stop after printing the No Omega image to the screen.

Unfortunately, this method also provided a way to bypass solving the first two lines of the riddle, if you noticed the jump in the line numbers, and simply removed lines 1110 to 2130 from the code.

The way I intended this to be solved is as follows. Remember those 4 bytes that came before the C64 code in the embedded data? BC 1A 00 00? 4 bytes = 32 bits. It's a 32bit integer in little-endian byte order. "The little end of thirty-two". So, 1ABC = 6844. "Shall say where the Omega lies". The meaning of Alpha in the riddle is obviously the alpha channel, but when mentioning Alpha and Omega together, they take on the meaning of "the beginning and the end". As such, in this context, the 6844 is supposed to tell you where the end of something is. If you take the first 6844 bytes of the C64 code, you will get everything up to and including line 3040, cutting off lines 1110 to 2130.

However you solve that bit, the new image you get looks like the attached image called finalscreen.png.

Two of the four 5-hex-digit groups are fairly obvious to spot. They are drawn using the special graphical characters in the PETSCII character set used on the C64. Indicentally, this also made solving the puzzle by analyzing the C64 code a difficult proposition, since the PETSCII character set does not exist on any other platforms.

The last two groups proved a lot more difficult for a lot of people than I had anticipated. They are color-coded as white into the image in the same parts as the drawn characters. They are very hard to discern precisely by the naked eye due to the randomness of the drawn characters, but map them out onto checkered paper, and they are very easy to recognize. I did try to make them easier to spot by removing the brightest of the C64 colors from the list of colors used to randomize the background, thus making the contrast to the white characters greater.

Having found all four groups of hex characters, all that remained was to determine the order they belonged in. Considering the drawn characters as the front layer (easiest to see), and the white characters as the back layer (hardest to see), the sequence is top-front, top-back, bottom-front, bottom-back.

The game code, and the final solution, is: 56265-F5EF7-5E45E-963E8

I hope you enjoyed this puzzle. I certainly enjoyed making it, and sharing it with you all :-)

Feel free to discuss it now.

Thanks, Wishbone.

Great puzzle. Very fair; you could solve it completely without any hint. Nothing arbitrary about the solution.

I recognised the alpha hint immediately as soon as you posted (we used to encrypt messages into images back in school by storing them in the least significant bits of one of the RGB channels) and a check using a photo editor on some random pixels confirmed that some of them had alpha at 254 (or 99% as the photo editor told me) and some 255 (100%).

Unfortunately, although I did have free time at work, I didn't have Visual Studio installed on the PC there. And this week I was at home very late, so too tired to do anything.
This meant that the only tool I had at my disposal was a photo editing software at work. I used it to make those alpha pixels fully transparent (see attached) and then manually checked the first several bytes. Stupidly, since most of them weren't ASCII characters, I assumed this is not going to be text. What didn't help me was the fact that I was leaning towards alpha254 pixels being 0 (since that's the least significant bit of the alpha channel). I checked both ways, but either way bytes 3 and 4 were either 00000000 or 11111111, both non-ASCII, so I gave up on the idea of finding text there.
I spent more time anylyzing the image using all kinds of stuff in GIMP, till I gave up and reported to Wishbone, who asked me to simply decode the full thing. In retrospect, I should have remembered this is a programming challenge, and not a photo-editor challenge.

This Sunday I finally had the time to sit at home and write a program. The other 2 mistakes I made was spending too much time analyzing the No-Omega image, thinking it contains a hidden message and is not just a dead-end image, and failing to see the white-coloured characters (and later when seeing it; misreading 2 characters). In my esoteric challenge, you also got initially only 10 characters, and then had to change the code to find the remaining 10, so I was thinking of something similar being done here and you had to somehow change the C64 BASIC code too. In all those situations, Wishbone helped me (thanks!).

Excellent job, Wishbone. Hope there will be a sequel some time in the future. It was nice to be on the receiving end of this for a change.

I've seen several similar images from other solvers during the course of this ;-)
Hehe, I was about to tear my hair out when you told me. If you had only looked ahead one more byte to byte 5, you would have found the ASCII code you were looking for :-D
Like I also told you, several elements of this challenge were heavily inspired by your past esoteric exploits. The inclusion of the dead end (the No Omega image), which incidentally did require you to modify the code (by finding out where the real code ended), the parts of the puzzle requiring very different approaches, the warnings I gave in advance about what not to waste time focusing on, and the type of vague hints I gave to people who were stuck, all was inspired by your previous challenges.
I may very well construct another at some point, if I can come up with a good idea. I think I shall try to remove the need for doing actual programming the next time around though. I do feel that it narrowed the field of contestants too much.

Seeing the solution written out like that is quite satisfying, I must say. I personally would be interested to see one or several code snippets, to show how you solved the programming part of the puzzle.
I messed around for a while to try and code something, but failed horribly. I need to know!

The riddle in general is pretty cool, thankfully I know my way around in 3D (mostly Blender) and 2D, so I also almost immediately got the Alpha part of it.

Funnily enough I had the most problems (at least that's what it felt like) towards the end, with the hidden second set of characters and then assembling the parts into a working code.

Anyway, thanks yet again for creating this puzzle Wishbone, and for helping me out (very, very often). :P
I hope we'll see more of this type in the future, by you or someone else.
...that would be nice. :D

I actually did look up till byte 7 or so. But if you consider that out of 7 bytes 4 are non-text, you get convinced it's non-text.

That's the problem with confirmation bias: bytes 3 and 4 were definitely non-ASCII, so I had the pre-conceived belief that it's not text. And refused to see otherwise.

What didn't help me was:
_The first three ASCII characters are "10 ". I was looking for letters, so quickly dismissed values below 65.
_I spend more time looking at alpha254 being 0. In fact if you do it that way, the very first byte becomes 01000011 - the ASCII letter "C". The moment I saw it I thought "Cool! I'm definitely on to something; maybe it is text after all." Then "Oh wait! the most significant bit in all the other bytes is 1. I was right, this is not text."
Sure. As soon as I'm home I'll post mine. Used C#.

I was the one who didn't get this whole "the little end of thirty-two" part and found the real picture by analyzing the C64 Basic code. Actually I think it's pretty awesome that there are multiple ways of solving the puzzle. =)

Very nice.

Good to know I was reasonably close. I actually missed the (very obvious) alpha reference and read it only as a reference to the start (and Omega the end) but after a false start (quickly corrected by Wishbone) I quickly spotted the alpha channel after playing around with the brightness of the image (I assume that was what the clue meant).

After that is where I stumbled. I turned to PHP to analyse the image (as language I am second most familiar with, I didn't think Javascript would have the capabilities needed) but it wouldn't actually recognise the alpha channel. And after trying to play around with it in Photoshop I realised that didn't recognise the alpha channel either (presumably as it was 99% opaque and 1% transparent) so I couldn't even change the image to black and white or something else PHP would recognise more easily.

And then I ran out of time and was too busy with other things to try again.

Really nice puzzle though Wishbone, I'm just sorry I couldn't finish it properly myself.

I've done it all with JavaScript. It allowed me to output the new image (the one with the pattern) superimposed on the original and also side by side. The way you do it is render the original image to canvas, then treat it as an array of pixel data to grab whatever info you need.