unforum

[xilope]

Re: [Puzzle] Audio Files hiding steganography

[pjv2]

I like your thinking on Japanese txt. I don't think it is though because of the high incedence of non japanese characters.

It isn't unusual for a gif, jpeg, wav or mp3 to look like japanese text when open in a text editor.

[MrMarbles]

I did a hex dump on the text files hoping to find something, but to no avail.

[TracerX]

Well, just for grins I ran trid on the jersey.txt and it found no matches which means that the file doesn't match the binary signature of 1198 known filetypes. I'd say its safe to say that it is no image or sound file unless the file header has been removed (or unless we need to decrypt all the files and put them together somehow, who knows).
Edit: yeah, I hex dumped jersey.txt too and while some of the hex proved to be chinese symbols (according to some pl.wikipedia.org unicode list) I couldn't get babblefish to make heads or tails of it.

[pjv2]

what tool did you use to determine the file types?

I've been messing around trying to dump it into different file headers but nothing will render it yet.

Hopefully we'll hear back on the likelyhood that this is a coincednce soon.

[persimmon8]

I've been poking around the original .wavs. The only thing I found that's even slightly interesting steganographically speaking are some of the chunks.

.wav files are broken into chunks. Each chunk has a label. In the axon .wavs, there's a chunk called "fact" (you can see those letters if you load one in a text editor). The next four bytes contain the size of the rest of the chunk: 4 0 0 0, which resolves to "4". The next four bytes are the remainder of the "fact" chunk, and they're different in every .wav file.

The "fact" chunk is only necessary when the audio data has been compressed using certain codecs. The codec for these .wavs doesn't need it. In fact, if you take out the "fact" chunk (all 12 bytes of it), the files play just fine.

Also, if the "fact" chunk were *actually* giving information about the compression method, it would probably be the same for all the files, but it's not.

So: this could all be the result of some audio software that puts "fact" chunks in whether or not they're needed. Or, it could be a clue. Since they're "fact" chunks, and the Queen is searching for the truth, there's at least a tenuous link.

- Per

[TracerX]

Interesting find there on the fact chunk. Maybe if we pulled all of them out, something might turn up in at least one of them that could lead us to what to look for in the others.

As for what program I used, it is called trid http://mark0.ngi.it/soft-trid-e.html . However, my guess would be that if the header is missing that this program would be incapable of matching the file signatures so that may be the problem.

[pjv2]

did some quick research on audio codecs and the fact chuck. It seems that it is only optional for non-compressed formats. In compressed formats the 4-byte word tells the program the run time of the file.

[ElViento]

Chinese symbols?

Dana is in China

[msekolpsu]

That's a good observation. Anybody here read Chinese? Go download the file!

[Antiarc]

On a hunch, given the AIs' fondness for "steno" in the distorted webcam images, I'm looking at all the data as raw image data. The few mp3 files I've looked at haven't yielded anything, nor have the decoded wavs, or the steno files pulled from the mp3s. However, I've just scratched the surface of the files, so if someone else wants to pursue this angle as well, it might be worth trying.

Additionally, has anyone tried wrapping those files in .wav headers and playing them?

[pjv2]

I tried inserting them into wave headers with no success. I really didn't know what I was doing though.

Also tried it with image formats.

the jersey.txt file loads as a raw with the correct dimensions, but it don't think this is really signifigant.

[sherpa]

[pjv2]

[Antiarc]