>>146083
I meant looking at the internal data bytes. Still working on it. What's curious is why this thing is split into two data blocks inside the image data.
The framework around Q's presence in here cannot be an accident. We assume it's a team; we don't know who ANY of them are, when they'll be back, or even if after every appearance. And we don't know how closely Q is monitoring traffic in here while he's/she's/they're inactive posting.
It all has the tendency to keep politics off the board and keep people focused. You might not expect that to be the result of such a setup, but it seems to be what's happened.
That's what I'm wondering. I still have to finish reading through the specs for the PNG file, to see if a block can be defined but not displayed. I just don't have any experience working with the internals of that format; never had a reason to go into it.
That's a very good point … once the stuff is downloaded onto a flash drive (or whatever), unplug it from the computer and do not plug it back in for any reason (unless instructed to do so by Q). Otherwise, as you said, it'll erase. Or get corrupted or whatever the "let's fuck these people" flavor of the month currently is.
I tried flood-filling the areas and got no interruptions whatsoever, so it appears to be solid black (say WHA?) with no shenanigans going on.
And the White Hats are probably sitting back in their comfy chairs laughing at us idiots spinning our wheels … ha ha they have no clue … but then, this is the kind of thing we do - investigate - and it's what we're expected to do. So who knows. Q will get back to this image when it's time. Meanwhile my curiosity is going to move me forward.
There are header fields that mark it as a PNG, and ALL internal fields were correct for a PNG format.
Ok kiddies … listen up!
I just removed (entirely) the second image data block from Q's PNG file. It displayed exactly the same. So that block is completely redundant and MUST contain "our special data."
I don't know MUCH about PNG internals because I've never had to delve into them before. The graphical Q map is generated entirely with manual byte-by-byte building of the BMP file with an all-assembly app. I've written network packet drivers, disk drivers, you name it. I am not lacking in knowledge or experience - except about the specific internals of the PNG file.
Removing the first block (which is what we see) and leaving in the second to display still saves as a valid PNG that shows up as all black. Flood filling it to red shows no non-0 (black) pixels.
Today I will be manually hand coding the decompression code for the data blocks. Most initiates would run to ZLIB or whatever else is out there. I am not a newb. I write my own; it's the only way I can trust it.
LEARN PROGRAMMING.
This is most curious. I just found and verified 277, 681 bytes of non-displayed data uploaded by Q and not a single person is interested in it.
Why would that be? That's definitely not the response I'm getting on Twatter.
I removed the one we see displayed, leaving in only the "extra" block. It showed up all black. Again, I'm still getting my feet wet with PNG files specifically (as far as their internals) so as soon as that decompression app is done I'll post what I find. If it's valid data, it will most likely be encrypted but we'll see.