Those 5 characters represent the first "T". Another "T" won't necessarily result in the same code. Actually, the odds of ever seeing that code again for a "T" is low.
You are right. Congrats!! There is actually an exclamation point at the end, but close enough! send an email to erik@carwoo.com and we can figure out how to get you the $500. Also, if you would detail your solution...that would be awesome!
[Do not read further if you want to solve it yourself]
1. The encoded string can be divided into groups of chars, each representing one (decoded) char. These groups occur every 5, 7, 11, and 13 chars. That is, chars 0-4 correspond to group 1, chars 5-11 correspond to group 2, etc. After the first 4 groups, the lengths repeat. Thus group 5 is chars 36-40.
2. As hinted in this thread, the space is of 59 chars, and there's an offset of 32. So, for each char in each group, subtract 32, sum them up, mod by 59. Add 32 to this result, and that's your decoded character ascii code.
Example: "!8F2>" corresponds to [33, 56, 70, 50, 62]. Subtracting 32 from each of those is [1, 24, 38, 18, 30]. The sum of those is 111. 111 % 59 = 52. Adding back the 32 offset, yields ascii code 84, corresponding to "T".
It never encodes things the same each time your run it, but they can all be decoded the same way. There are no strange initial conditions you need to know about like time or some other kind of token.
Erik says that all of the strings can be decoded with the same method. Since the input string can result in multiple different valid encoded forms that implies to me that the method for decoding these strings is also encoded in the string (it seems that otherwise we would have to guess magic inputs).
However, assuming that approach, it is interesting to me that each resulting string ended up the same length. Trying to tease out some encoding code from the outputs now...
Are you sure it's exactly 8? I get ~8.9 times its own length.
var fox = "THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG";
var decodedfox = atob("SDdRJFYxMSUmPT5WKD85Kzk+Mi8kK0QmJDY2VkMuRTROJT0hLk03KTFGRjUuSiAyPyhRUjNaOlJFTTYqSUNKUFRVMFZLR009IDpKLDY1IU5JKTZFMywnICY8VUROUC8hISBBIzMiLCNBJy1JPyI/T1Y/R1AiLTQ0WT0pPFMjLidLV00ySDpNNTAwJkZJRyNNMVVPSVkuLC9GIyYyLDFNSjZDNi0oIy5QOyE3OiFLIzUiKldDM01UQylTS0hVLSc3OFFDJyRQITRRWE85OlgtVzM7MjZGKElWK0dHT0FDPSgnTFUhUjtXSDZKQ1cjUjYyPFU7OVZPLEYvPkg1TERXIzEpQTpLMFRQJT9SMjNBWE40N1UhLCEjWSogRz1DMCM3WClAOkNKUD5QPykmMCtAIUNHIzdXLCk9JCVYJ0tGVFgxSSxGKyErJSVHTlJVVUQxOUJZLDklKD4yLChIMCc1I0Q3SUYhMTc9OicyKERSNFNOTiIpRz06USdENUVVRCE=");
console.log(decodedfox.length/fox.length);
I am working on the assumption that the first few chars could be a randomly generated salt and the rest is equal sized blocks of encrypted content. The random salt results in a different encoding each time.
This is what I have so far and it seems to fit the original encoded message too.
Quick thought: each byte is a printable ascii character between space (0x20) and 'Z' (0x5a) inclusive. All these bytes appear in all the encoded files. Does anything interesting happen if you interpret the files as encoded in base 59?
(Edit: obviously I'm talking about the files after they have been base64 decoded…)
The strange properties of the encryption lead me to believe it was some binary modification (just a pattern), but that may have been looking too far into the problem. I started to see a pattern by deleting bits initially but it disappeared as I progressed.
I'm not even sure where to start with using the unencoded string.
"A Christmas Story" is pretty great christmas movie. One of the greatest scenes is when Ralphie decodes the secret orphan annie message. I changed it a bit so that someone wouldn't just guess it.
it seemed fitting as it is the only encoded message in any holiday movie I could think of! :)
That range is 58 characters which (perhaps suspiciously) is size of alphabet + 2^5. (Although a whitespace character is also encoded, making that suspicion a little less "round".)
From comparing the multiple encodings of Quick Brown Fox, the value distribution across that range is fairly even and every value is used at least once.
the reason i base64 encoded it is that wordpress was trying to be smart and changing characters for me...which in a coded message is...not a good idea.
I'm aware of those problems, however I'm trying to confirm if the above is the same as what I should be trying to decode. It's a waste of time to decode the wrong string.
IThGMj4wS0gvR0M9PE5QQEEnMyxNIiFHJE1NVTdYSS5PTTdFT1FCVUtMLVBW Qj4nNkBUIDsqLUNTLjVCJS87IkwnT1E/LiZRI1E4ITlBLzBXNU5SNEgmVDM8 QFM0Ty4wLFAvL0ohNTUxQzU2Jy82LVEpN0gpSjs3NCE5Q1lXQlUwUVc1MUFX NDI7LUQnO09BSEI9WVdNRktOTTdLNkI+Pj5HIDtKS1YkSVY0I0pRPTtYVSY9 KyhZVEAqJykrJSIpIjcsI0ckWD4ySlRIIkAhUyw+VStUQVY/NiUpNFZVMis8 IylXMiU9VVFKSFI3WkI3S0A/QTMhIkkuP0pFMVJKQixYJSFGJz8+TD89WFgu JyRSJ1hYIlIoVEFVLlUwOjc0Oi4iQDlNOUVPSUdHOkM5Mj9LWilCMlkmPj1X M0otSiwmKFU4Jy9IJzc5WkFVQ1VFPFFAQ0tHOClYLDklPDs/T1BPS0hTPDAi WkRBQVVSOTIhKjxBR0ZNNypRNzwsMVI=
The first 5 characters are "!8F2>"
Those 5 characters represent the first "T". Another "T" won't necessarily result in the same code. Actually, the odds of ever seeing that code again for a "T" is low.