UPDATE 2
(Reorganizing the whole post to include only the parts that weren't dead ends)
The first mystery string, N5TYJJETNWRXJ6KBNAYYFJEGPOSXD4EG is decoded as follows:
Caesar_25("N5TYJJETNWRXJ6KBNAYYFJEGPOSXD4EG") -- A => Z, B => A, C => B, ...
= "M5SXIIDSMVQWI6JAMZXXEIDFONRWC4DF"
decode_base32("M5SXIIDSMVQWI6JAMZXXEIDFONRWC4DF") = "get ready for escape"
(Base 32 reference for those who haven't seen it yet: wikipedia)
The second mystery string:
KIZTEWS2LBKVOTCJJJBFCUCVGZEUQTCBKJAVKU2NKNIFOWSKKRIUIUCKK5ITGV2DINJE4V2LJ5KEGUC2I5LU6MSUKFBUUV2XKFIEUV2DKJHFOWKPKRCUIWSHK5FTEVCRINIE2V2RGNKFKQ2SJZBVKT2UINCVER2XKBFFIUKEKBFFOUJSJJMUGUSKLBKU6VCXIRNEOV2PKBKFCRCIJJLVCM2UKNBVETSDKVHVIQKEKBDVOWSJJJIUISSVK5ITGSSRINJEUV2DI5IQ
is decoded as follows:
decode_base32("KIZ...") = "R32ZZXUWLIJBQPU6IHLARAUSMSPWZJTQDPJWQ3WCCRNWKOTCPZGWO2TQCJWWQPJWCRNWYOTEDZGWK2TQCPMWQ3TUCRNCUOTCERGWPJTQDPJWQ2JYCRJXUOTWDZGWOPTQDHJWQ3TSCRNCUOTADPGWZIJQDJUWQ3JQCRJWCGQ"
Caesar_10("R32ZZX...") -- A => K, B => L, C => M, ...
= "B32JJHEGVSTLAZE6SRVKBKECWCZGJTDANZTGA3GMMBXGUYDMZJQGY2DAMTGGAZTGMBXGIYDONJQGU2DAMZWGA3DEMBXMEYDMOBQGZTDANZTGA2TIMBTHEYDGNJQGYZDANRTGA3DCMBXMEYDKNZQGJSTANTEGA3TAMBTGMQA"
The "B32" is a just a tag that says "hey, the rest of this is base32"
decode_base32("JJH...") = "JNCVSX2OJ5PTAXY2f07306f07506e06402f03307207505403606207a06806f07305403903506206306107a05702e06d070033 "
That string has 3 parts: 15 characters of base32 (ending with the Y, the last uppercase letter), 86 characters of hex (starting with 2f0730), and one trailing space which seems to serve no purpose at all.
decode_base32("JNCVSX2OJ5PTAXY") = "KEY_NO_0_"
The 2f0730... string, laid out in rows of 3, has an obvious structure:
2f0
730
6f0
750
6e0
640
2f0
330
720
750
540
360
620
7a0
680
6f0
730
540
390
350
620
630
610
7a0
570
2e0
6d0
700
33
Remove that column of 0's and you get a simple hex string in which every pair of hexdigits decodes into a printable ASCII character:
decode_hex("2f736f756e642f3372755436627a686f735439356263617a572e6d7033")
= "/sound/3ruT6bzhosT95bcazW.mp3"
which is a valid path on the server:
http://countdowntoreveal.com/sound/3ruT6bzhosT95bcazW.mp3
consisting of beeps (possible Morse code), voices (possibly Russian), and static. And static. And static.
The spectrogram of the audio looks something like:
UPDATE 3
Some thoughts about the new stuff: there is a strong suggestion we should extract the alpha channel from a PNG and view it as a separate image, but I've tried that on all the images on the page and none of them showed anything interesting. Also viewing the images without their alpha channels. One of the background images, /img/dg.png, has a little extra viewable area around the edges where the alpha channel was covering it up, but it's obviously only there for artistic effect.
UPDATE 4
I found the last piece of the rar archive at http://www.countdowntoreveal.com/cam04/corrupt3.rar
I probed http://www.countdowntoreveal.com/cam01/ through http://www.countdowntoreveal.com/cam99/ and got 404 replies from most of them. The exceptions were:
cam38 (which we already knew about, it gives a 403 reply when you try to get the directory)cam02 and cam04 (403 reply just like cam38 indicating that a directory does exist; only cam04 contained the corrupt3.rar we needed)cam01 cam03 cam11 cam12 cam33 cam34 cam35 cam36 cam37 - all of these reply to the directory query with an HTML page that says "NO SIGNAL" and "return", in the colors and font of the main page, with "return" being a link to the main page. There doesn't seem to be any hidden information on these pages; they're apparently just there to discourage people like me from persisting with a search long enough to find cam04.
With the complete rar file, we can now extract the DICOM image properly. Once again I'll have to shrink it to be allowed to upload it here.
In addition to the skyscrapers and helicopter and "CAM83" that we could see before, we have some text at the bottom of the image: "12:43:20:27" and "NODE 14-4 KORD".
The timestamp "12:43:20:27" appears in the text file c38error_log.txt and as noted by 2012rcampion it's out of sequence in that file. I don't know what to make of that.
A question was asked about the DICOM metadata. I don't see anything interesting in it. Some timestamps pointing to October 8, somet blank fields, basic image metadata (width/height etc.) Here's a dump, created by the medcon utility:
(0002,0000) UL[1] MetaElementGroupLength: 196 (4 bytes)
(0002,0001) OB[1] FileMetaInformationVersion: (2 bytes)
(0002,0002) UI[1] MediaStorageSOPClassUID: [1.2.840.10008.5.1.4.1.1.7] (26 bytes)
(0002,0003) UI[1] MediaStorageSOPInstanceUID: [1.2.276.0.7230010.3.1.4.3408318492.4584.1444297906.1] (52 bytes)
(0002,0010) UI[1] TransferSyntaxUID: [1.2.840.10008.1.2.1] (20 bytes)
(0002,0012) UI[1] ImplementationClassUID: [1.2.276.0.7230010.3.0.3.5.4] (28 bytes)
(0002,0013) SH[1] ImplementationVersionName: [OFFIS_DCMTK_354] (16 bytes)
(0008,0016) UI[1] SOPClassUID: [1.2.840.10008.5.1.4.1.1.7] (26 bytes)
(0008,0018) UI[1] SOPInstanceUID: [1.2.276.0.7230010.3.1.4.3408318492.4584.1444297906.1] (52 bytes)
(0008,0020) DA[1] StudyDate: [20151008] (8 bytes)
(0008,0021) DA[1] SeriesDate: [20151008] (8 bytes)
(0008,0030) TM[1] StudyTime: [095146] (6 bytes)
(0008,0031) TM[1] SeriesTime: [095146] (6 bytes)
(0008,0050) SH[0] AccessionNumber: (no value)
(0008,0060) CS[1] Modality: [OT] (2 bytes)
(0008,0064) CS[1] ConversionType: [WSD] (4 bytes)
(0008,0070) LO[0] Manufacturer: (no value)
(0008,0080) LO[0] InstitutionName: (no value)
(0008,0090) PN[0] ReferringPhysiciansName: (no value)
(0008,1030) LO[0] StudyDescription: (no value)
(0008,103E) LO[0] SeriesDescription: (no value)
(0010,0010) PN[0] PatientsName: (no value)
(0010,0020) LO[0] PatientID: (no value)
(0010,0030) DA[0] PatientsBirthDate: (no value)
(0010,0032) TM[0] PatientsBirthTime: (no value)
(0010,0040) CS[0] PatientsSex: (no value)
(0020,000D) UI[1] StudyInstanceUID: [1.2.276.0.7230010.3.1.2.3408318492.4584.1444297906.2] (52 bytes)
(0020,000E) UI[1] SeriesInstanceUID: [1.2.276.0.7230010.3.1.3.3408318492.4584.1444297906.3] (52 bytes)
(0020,0010) SH[0] StudyID: (no value)
(0020,0011) IS[0] SeriesNumber: (no value)
(0020,0013) IS[0] InstanceNumber: (no value)
(0028,0002) US[1] SamplesPerPixel: 3 (2 bytes)
(0028,0004) CS[1] PhotometricInterpretation: [RGB] (4 bytes)
(0028,0006) US[1] PlanarConfiguration: 0 (2 bytes)
(0028,0008) IS[1] NumberOfFrames: [1] (2 bytes)
(0028,0010) US[1] Rows: 816 (2 bytes)
(0028,0011) US[1] Columns: 1866 (2 bytes)
(0028,0100) US[1] BitsAllocated: 8 (2 bytes)
(0028,0101) US[1] BitsStored: 8 (2 bytes)
(0028,0102) US[1] HighBit: 7 (2 bytes)
(0028,0103) US[1] PixelRepresentation: 0 (2 bytes)
(7FE0,0010) OW[1] PixelData: (4567968 bytes)
UPDATE 5
All the /camXX pages now say "Online"...
Actually, the ones that were 403 Forbidden or "NO SIGNAL" have changed to "ONLINE", the 404's (at least some of them - I didn't try them all again) are still 404, except for cam83 (which is now "ONLINE"). That's definitely interesting.
So /cam83/ exists now where it didn't before. By analogy with http://www.countdowntoreveal.com/cam38/c38error_log.txt I suspected http://www.countdowntoreveal.com/cam83/c83error_log.txt might exist and I was right. Here it is:
################################################
09:17:12:00,133 ###*#*#*@# fai&*###*#*#*@# fai&*
09:17:13:02,045 g a#sted service.
09:17:14:50,553 ting s#### 1450 In@#$$ficient sys##########
09:17:16:12,423 o# "@###@@#*@###*#*#*@####*#*#*@#50
09:17:17:00,045 RVJST1JfQUNDRVNTX0RFTklFRCA1ICgweDUp
09:17:18:03,453 RVJST1JfRklMRV9OT1RfRU5DUllQVEVEIDYwMDcgKDB4MTc3Nykg
09:17:23:10,023 #####*#*#*@# fai&*@
09:17:25:00,885 ERROR_FILE_NOT_FOUND 2 (0x2)
09:17:26:06,053 k## or restore op##ation termi###tin
09:17:27:10,603 RRnough server sto#age is av4$@able to
09:17:29:00,035 ERROR @$$50: / hex #SYSTEM_RESOURCES
09:17:35:03,553 RVJST1JFUlJPUkVSUk9SRVJST1JFUlJPUkVSUk9SRVJST1JFUlJPUkVSUk9SRVJST1JFUlJPUg==
09:17:36:55,023 ERROR_PATH_NOT_FOUND 3 (0x3)
09:17:38:04,275 ##UNDEFIENED##
09:17:45:00,053 Key value 128 ##UNDEFIENED##
09:17:47:33,323 U2FsdGVkX18z6MR5KMT9DfGS3bP/YMBPnLkbfGNxPZgMR1817s89jBvWPb1WgRa6pP4ZJYNKTAw92hCrEzHVa3LtCK/Xt4yQIFogTBFSzcZ1aOP24BOFkJmaTYmlrHi9QWdESfji5ITIgt9JD8fmX6og9Wl8XZ29rhAIeImVPfShsLEVTswtE1vEM+IiX/xr9UvUql50r0RaN0abjbGQsQ==
09:17:48:07,035 Back## or###*#*#*@# op##ati###*#*#*@#mi###ting a####ly.
09:17:49:00,553 ERROR_PATH_NOT_FOUND 3 (0x3)
09:17:51:20,303 U2FsdGVkX18vM/BTHII1L4LTlvfkMjaB7s/84Al/y1L0hcUGGyMyeARy1TKnL90nB092FcSq2QnHcx03QrIauV6pG5oyisvxqzsJAMuD9gk=
09:17:54:00,325 ##UNDEFIENED##
09:18:15:50,553 T3BlcmF0aW5nIHN5cyMjbSBlcnIjIyAxNDUwIEluQCMkJGZpY2llbnQgc3lzIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
09:18:18:12,523 Key value 256 ##UNDEFIENED##
09:18:19:00,025 hoBFujy/ucmQE6rOElwIxy9aCmDRXlnFtoJ9raVHsbI=
09:18:22:03,453 RVJST1IgMTEzMDogTm90IGVub3VnaCBzZXJ2ZXIgc3RvI2FnZSBpcyBhdjQkQGFibGUgdG8gIyNjZXNzIHRoaXMgY29tbWFuZC4=
09:18:25:10,023 ZXJyb3IgYSMjZXNzIExAI0skICNETUw6SiMjICMoKSok
09:18:26:00,835 Back## or###*#*#*@##ati@#mi###ting a####ly.
09:18:28:06,053 em reso@@#ces exist $$ complete the
09:18:34:10,343 ERROR_PATH_NOT_FOUND 3 (0x3)
09:18:45:00,035 S5tem co4ion EBa###*#*#*@# op##ati###*#*#*@#mi###ting a#sted service.
09:18:55:03,353 RVJST1JfRklMRV9OT1RfRU5DUllQVEVEIDYwMDcgKDB4MTc3Nykg
09:18:57:55,033 RVJST1JfQUNDRVNTX0RFTklFRCA1ICgweDUp
09:19:18:04,675 erat@#######*#*#*@#es exist $$ complet
09:19:25:00,053 ERROR_ACCESS_DENIED 5 (0x5)
09:19:27:33,373 m co4ion EBa###*#*#*@# op##ati###
09:19:28:07,035 ERROR_FILE_NOT_FOUND 2 (0x2)
09:19:39:00,853 ERROR_N$$%SYSTEM_RESOURCES
09:19:41:20,303 # ption
09:19:44:00,025 # c##r
################################################
These 3 lines of base64 are especially interesting:
09:17:47:33,323 U2FsdGVkX18z6MR5KMT9DfGS3bP/YMBPnLkbfGNxPZgMR1817s89jBvWPb1WgRa6pP4ZJYNKTAw92hCrEzHVa3LtCK/Xt4yQIFogTBFSzcZ1aOP24BOFkJmaTYmlrHi9QWdESfji5ITIgt9JD8fmX6og9Wl8XZ29rhAIeImVPfShsLEVTswtE1vEM+IiX/xr9UvUql50r0RaN0abjbGQsQ==
09:17:51:20,303 U2FsdGVkX18vM/BTHII1L4LTlvfkMjaB7s/84Al/y1L0hcUGGyMyeARy1TKnL90nB092FcSq2QnHcx03QrIauV6pG5oyisvxqzsJAMuD9gk=
09:18:19:00,025 hoBFujy/ucmQE6rOElwIxy9aCmDRXlnFtoJ9raVHsbI=
The first and second both decode to something starting with the 8 character string Salted__ followed by random-looking bytes. That format is consistent with the output of the openssl enc command. The third base64 decodes to 32 random-looking bytes (0x86 0x80 0x45 0xBA 0x3C 0xBF 0xB9 0xC9 0x90 0x13 0xAA 0xCE 0x12 0x5C 0x08 0xC7 0x2F 0x5A 0x0A 0x60 0xD1 0x5E 0x59 0xC5 0xB6 0x82 0x7D 0xAD 0xA5 0x47 0xB1 0xB2), which could possibly be a key for symmetric encryption.
UPDATE 6
After much unsuccessful guessing, I decided to try brute force on the encrypted strings. I made a special-purpose program to do it (openssl enc stripped down to have no features except the minimum necessary to try a bunch of passwords with aes-128-cbc on a single hardcoded input). I fed it a word list and got nothing. I fed it a bigger word list and got nothing. There was nothing left to do but try feeding it all possible passwords, starting with short ones and working up to longer ones.
It turns out the password is 1.
The decrypted text is
ares and mars h##e s#mething in co#mon, but are p##ntless wit%%#t their r^%@# which *&@&*&($ truth for whole bunch of people %##$#@#$###
The second encrypted string was also encrypted with the password 1 but it used aes-256-cbc. The lines 09:17:45:00,053 Key value 128 ##UNDEFIENED## and 09:18:18:12,523 Key value 256 ##UNDEFIENED## are probably hints about the different key sizes.
The second string decrypts to this:
ERROR @$$50: / hex ##5aa ERROR_N$$%SYSTEM_RESOURCES
So the first encrypted string is some weird stuff about "ares and mars", the second is just more of that fake error stuff we've seen already, and the third one is still a mystery.
