I converted the coded data presented in the bootsector page to files using hex editor, tried to pad the values to get whole 4byte words, tried the reversed to original uniqueids unpadded and padded and the results are: the file signature of the initial bytes are not recognizable by any means, the 0x95 first byte could point to SKR PGP secret keyring file, but the starting bytes needed to be 0x95 0x00 or 0x95 0x01.
So no luck with these approaches.
Iāve been trying to insert the full data block or just the āholeā data in many files (jpg, png and pdf; getting sick of it to be quite honest), however I noticed that all modified files become un-readable EXCEPT the map.jpg from CSD (the one called āloop16ā, with the out of focus and glitched night sky or star map).
For instance if we modify the 3&half bytes from 0x38Df (=14559), we can still open the file in a viewer. We see some kind of shadow if we modify enough, but couldnāt quite make something out of it so farā¦ but ā¦
EDIT: one thing I havenāt tried is to rotate the āpunch-cardā counter clock wise (because the holes look like 16 that way) and use the data in that order instead, but I am losing steam here!
Thatās the other thing I thought. The file could be encrypted using a 56-bit DES3 encryption.
I wrote a simple Java program to convert the hex values into ARGB and RGBA with 8-bit alpha channels but that was a bust (at leaset as far as Paint Shop Pro was concerned). Iād run down the encryption angle. The ARG people have already said that phase 2 is supposed to be a lot harder. Maybe weāre supposed to break a 56-bit encrypted message?
An idea I just had: If we do convert the hex data into a code, it could be something we input to Loop16. It might convert it into a usable link for us like it converts emails into hyperlinks.
How do you envision this?
I have not seen any loop16 instruction that accepts commands, and even so, converting hex into code makes no sense, hex is a way to represent machine instructions, so if they are that, you should be able to just feed it the hex.
Hereās a theory that I am working on in case anyone else wants to offer their insightā¦
When examining the āmap.jpgā image using http://mirror.otp22.com/jhead, I found that it has some blocks of data that are not valid JPEG data as far as being synced up with the JPEG marker codes. This data appears different from normal JPEG data. JPEG data is highly compressed and is therefore fairly random. If you look at the range from 0x00FB to 0x1F86 in map.jpg (one of the suspicious portions of the file), you will see that the data looks like it varies over a smaller range of values, as it would be if it were uncompressed audio, for example.
This could mean that some other file needs to be inserted there, as others have suggested, but it may also mean that some data needs to extracted from map.jpg.
So I believe we may have a file with steganographic messages hidden inside. There are online steganography tools such as Steganography Tools but I was not able to guess a password that worked. Maybe someone else can come up with something.
I also think that we are supposed to do something with map.jpgā¦ I like your idea of audio being hidden in it, have you tried extracting that portion of the file and make a .wav out of it?
Where can I download this map.jpg?
Can you plz send a link to the map.jpg file ?
click on the right side icon and the image (stars) appears
What about the old glitched PDF image with all the zeroed-out bytes?
I did the same (see above) and I do see visible change, but I canāt read text though
Could you post your patched map file?
Also, did you try injecting the bytes into the full note image that was given to us? The one that we found a PGP marker in?
Probably not! Which file is that again (with the PGP marker)? I thought that file was not official?
That said, Iāve had enough of it. Iām closing HxD forever !! xD
Itās a png file, so I donāt know if injecting bytes is possible. But: http://bootsector.wakingtitan.com/uploads/a5d59b2d-e00d-4fad-a692-f769e84feb72.png?07232017154745
looking at all the numbers
first 3 letters are DCE
DCE Data Collection Event
it does appear looking at the full list of number
it appears to be intel opcodes,
i do think the data start after DCE
I dont think so. Too many invalid opcodes.
nice, thanks
