Quote from: kn0w0n3 on January 15, 2018, 08:17:32 PM

Quote from: clanestutr on January 15, 2018, 07:54:06 PM

Quote from: itod on January 15, 2018, 06:50:05 PM

Quote from: kn0w0n3 on January 15, 2018, 06:00:44 PM

@Itod, so in your opinion the "The_____iskeyfile" message is the intended message?

Well, I have a theory didn't want to mention before while trying to find the proof. The message "THEfm_aurISKEYFILE" can hardly be a collision, and the bold scrambled part is intentionally left there to be de-scrambled in the same way other bit-streams should be de-scrambled to get a key. If you come across the stream of bytes from private key you may not notice something is scrambled, but if you find something like plaintext quoted above it's pretty obvious something is wrong. So to answer you: yes I think it's intentionally left there scrambled/corrupted to show the way.

Anything can be the way to de-scramble it in a coherent message. The current path I'm working are the chessboard fields affected by Phoenix fire. It looks to me that those chessboard fields that should be dark are somehow lighter with this bright blue Phoenix color then the white ones, so some bits associated with those chessboard fields should be inverted in raw bit-streams. I believe if we invert some bits from the "THEfm_aurISKEYFILE" bit-stream, in this way I've described, we will get coherent message from this bit-stream, and then we should apply this same transformation to colors bit-streams to get the private key.

Why "keyfile" though?

Perhaps the odd word choice was needed to create/preserve the 0x1x1x0x1x1x0 pattern.

This is the one thing that's tough to reconcile. The message overlaps with the pattern bits which would indicate it's not really there. The original dataset was only 2GB large. Presuming mostly random data the chance of finding just the "iskeyfile" text in that small of a search space is 0.098%. Both eventualities are equally unlikely.