›

An Interesting Trick

BadwolfBadwolf
edited July 2007 in General Chat
Here's a quick picture of Guybrush I sketched up the other day. He's hiding something though.

54cl200.png

Try saving the picture to your desktop and opening in your favourite music player (as long as it's not Windows Media Player) to find out what he's hiding. Winamp and Media Player Classic both seem to do the trick if you can't get it working.

I'll explain how to do this later if anyone wants.
(Kudos goes to a member on another forum I go on, who stole the idea from somewhere else and told me about it).

Comments

  • MaratanosMaratanos
    edited July 2007
    Ooooh, fun!


    "We'll surely avoid scurvy if we all eat an orange..."
  • DerwinDerwin
    edited July 2007
    MPC does not work... cannot render file... is he hiding the codec necessary?
  • BadwolfBadwolf
    edited July 2007
    Hmm, I don't know why that is. I'm using version 6.4.9.0 if it helps?


    Anyways, here's how I did it for anyone interested, now I've got the time to post it:

    Firstly, get the two original files you want to merge (it seemed to work best with pngs and mp3s for me) and put them in the same directory.
    Then open Notepad or anything similar, and paste in (substituting anything in the squared brackets as necessary):

    copy /b "[image name].png" + "[sound file name].mp3" "[merged file name].png"

    Save it into the same directory as the other files with the name [something].bat (I used merge.bat, but it doesn't matter what you call it as long as it's a .bat).

    Now just run the bat file and with any luck, the merged file should appear in the same directory.


    I've just tested it with text files in place of the mp3 file as well, and that seems to work quite well (open the png through Notepad and the merged message should be at the end of all the gibberish the picture itself leaves).
  • jmmjmm
    edited July 2007
    That is not a trick, its a bug (reading beyond end of data)

    Its based on the same concept of the "JPEG virus/trojan"

    To ease the creation of a merged file, you can try this batch file (save as "merge.bat")
    @echo off
if '%1'=='' goto err
if '%2'=='' goto err
if '%3'=='' goto err
copy /b %1+%2 %3 > NUL
goto end
:err
echo Usage: merge file_1 file_2 output_name
:end
  • ReverendTedReverendTed
    edited July 2007
    jmm wrote: »
    That is not a trick, its a bug (reading beyond end of data)

    Its based on the same concept of the "JPEG virus/trojan"
    Are you sure that's technically correct in this case? To me it seems like the png only reads to the end of the png data (there isn't MP3 gibberish trailing at the end of the displayed image), and the MP3 portion skips to the metadata tags (or whatever) that define the start of the MP3 content.
    (I noticed in the Winamp file properties that it said "Header found at: 5267 bytes".)
    It's not like either program (png viewer\mp3 player) is writing the additional "payload" into vulnerable memory - to me it seems like they're both handling it properly.

    Thanks for the batch file!
  • jmmjmm
    edited July 2007
    Yes, it’s a bug. The specs for the PNG data format states that the IEND chunk marks the end of the image. If the software continues to read after the end it’s clearly a bug.

    I know that from a technically strict standpoint this is not the same as the JPEG virus, but it is still close:
    If you alter the IEND chunk, maybe you can execute code with badly written decoders or renderers. Haven't tested it, probably will if I have time.

    PNG Specifications can be found at http://www.w3.org/TR/2003/REC-PNG-20031110/
  • ReverendTedReverendTed
    edited July 2007
    jmm wrote: »
    Yes, it’s a bug. The specs for the PNG data format states that the IEND chunk marks the end of the image. If the software continues to read after the end it’s clearly a bug.
    But the software doesn't continue to read after the IEND chunk. (Only the standard PNG data is displayed.) The PNG display software (in my case, PSP6) functions properly according to the specifications without buffer overrun of the MP3 data portion of the file.

    Similarly, the MPEG3 specs state that the MP3 header marks the beginning of the audio - and the software I've used so far (WinAmp) identifies the MP3 header indicating the audio data, again, functioning according to spec and not loading the PNG data into memory.

    The JPEG vulnerability arises when the malformed file causes a standard-compliant JPEG renderer to load an additional payload into memory - in the case of a trojan the addition payload would be executable code.
    I would expect (but couldn't state for sure) that most standard-compliant PNG renderers would simply reject a file with a malformed IEND tag.

    Edit: According to section 13.2 of the PNG specification (thanks for the link!), a standard decoder could actually IGNORE a malformed IEND chunk, but errors in compressed chunks (IDAT, zTXt, iTXt, iCCP) could lead to buffer overruns. As such, they recommend "Implementors of deflate decompressors should guard against this possibility." This suggests that memory is allocated for a PNG in such a manner that a malformed IEND chunk could not result in a buffer overrun anyway. Section 13.4 deals with security considerations specifically.
  • jmmjmm
    edited July 2007
    ReverendTed wrote:
    The JPEG vulnerability arises when the malformed file causes a standard-compliant JPEG renderer to load an additional payload into memory - in the case of a trojan the addition payload would be executable code.
    I would expect (but couldn't state for sure) that most standard-compliant PNG renderers would simply reject a file with a malformed IEND tag.

    I altered the IEND tag, so far the malformed data is ignored, and the image is still displayed. Will try with compressed chuncks.
Sign in to comment in this discussion.