Parsing Pictures in a PowerPoint binary file


In this blog I’d like to cover every aspect of parsing Office binary documents, and do it in less than a thousand words.  But, what follows is more realistic, thus more narrow in focus.  Specifically, I’ll examine the PowerPoint binary format from the point of view of parsing/enumerating “Pictures”.  PowerPoint Pictures are found in the Pictures Stream (as you will see below).  By contrast, Shape objects (rectangles, squares, lines, etc) do not exist in the Pictures Stream.  So the discussion and details of the enumeration of Shape objects may be the subject of a future blog.


There are several Office binary file formats defined as part of the Open Specification document set and you can find them detailed here.  The one for which I’ll focus my angle of approach is the PowerPoint binary file format specification (MS-PPT).  And, since you can’t find Office pictures in a binary document without referring to the MS-ODRAW specification, much of the details of this blog will derive from definitions of structures in MS-ODRAW.  Since this analysis is specific to “Pictures”, which means an actual inserted picture in the PowerPoint document, to follow along you may refer to MS-PPT section 2.1.3 Pictures Stream: An optional stream whose name MUST be “Pictures”.  The contents of the Pictures Stream are defined by the OfficeArtBStoreDelay record as specified in MS-ODRAW section 2.2.21.


Looking at MS-ODRAW section 2.2.21 OfficeArtBStoreDelay: This record specifies the delay loaded container of BLIPs in the host application. There is no OfficeArtRecordHeader for this container.

rgfb (variable): An array of OfficeArtBStoreContainerFileBlock records that specifies BLIP data.  The array continues while the rh.recType field of the OfficeArtBStoreContainerFileBlock record is equal to 0xF007 or between 0xF018 and 0xF117, inclusive.


For an example, I created a very simple MS-PPT document and inserted (Menu Ribbon -> Insert Tab) a Picture and a ClipArt object.  Based on the above specification details I’ll enumerate the image objects, as shown below (Hex file view after opening the Pictures Stream and delving to the OfficeArtBStoreContainerFileBlock).


You’ll find the color coded details below, which explain this hex data block.

A0 46 1D F0 AE 03 00 00 B1 A6 19 08 D8 C3 0B 6F //image data follows

B5 6C A3 98 8C 9E F4 65 FF FF D8 FF E0 00 10 4A

…//skipping forward to the next record

60 21 1B F0 38 6D 00 00 27 CF 5A 3B 2E DC 9E 2E //image data follows//

16 A1 A1 59 52 1B 76 E9 AC A7 00 00 DC F7 FF FF


The first type of image object shown above is the JPEG I inserted, as shown in MS-ODRAW section 2.2.22 OfficeArtBStoreContainerFileBlock:

Value            Meaning

0xF007           OfficeArtFBSE record

0xF018 – 0xF117  OfficeArtBlip record


I am only dealing with OfficeArtBlip records in my example, so MS-ODRAW section 2.2.23 OfficeArtBlip (note color coded hex dump above):

Value  Meaning

0xF01A OfficeArtBlipEMF  record

0xF01B OfficeArtBlipWMF  record

0xF01C OfficeArtBlipPICT record

0xF01D OfficeArtBlipJPEG record

0xF01E OfficeArtBlipPNG  record

0xF01F OfficeArtBlipDIB  record

0xF029 OfficeArtBlipTIFF record

0xF02A OfficeArtBlipJPEG record


The first record is the OfficeArtBlipJPEG, MS-ODRAW section 2.2.27 OfficeArtBlipJPEG:

rh.recVer      MUST be 0x0.

rh.recInstance Specified in the following table.

rh.recType     MUST be 0xF01D.

rh.recLen      An unsigned integer that specifies the number of bytes following the header.

MUST be the size of BLIPFileData plus 17 bytes if recInstance is 0x46A or 0x6E2 or the size of BLIPFileData plus 33 bytes if recInstance is 0x46B or 0x6E3.


0x46A    JPEG in RGB color space

0x46B    JPEG in RGB color space

0x6E2    JPEG in CMYK color space

0x6E3    JPEG in CMYK color space


Since 0x3AE = 942 bytes you would read the header record and note the type of the record (0xF01D) and skip forward 942 bytes to the next 8 byte header record and repeat while you had records to read in the Pictures Stream.  In this example, I have only two records, and would read the next record as 0xF01B OfficeArtBlipWMF, which is length of 0x6D38 = 27,960 bytes.


The following sample code snippet demonstrates how to delve the stream structures with IStorage.  You may use this as a simple starting point in your investigation of the Office binary file structures.  (Note, of course, you will want to implement with error handling and other coding best practices.  This is only a small snippet I used in this example to investigate the stream structures with IStorage)


int main(int argc, char* argv[])


      HRESULT hr;

      IStorage *pStg = NULL;



      hr = StgOpenStorage(

            L“<path to file>\\powerpoint-file.ppt”,



      if (!FAILED(hr))


            IEnumSTATSTG *pEnumStat = NULL;


            DWORD dwFetched;

            STATSTG stat;


            while (pEnumStat->Next(1,&stat,&dwFetched) == S_OK)


                  if (!wcscmp(LPictures,stat.pwcsName))


                        IStream *pStm = NULL;

                        hr = pStg->OpenStream(


                              NULL,STGM_READ | STGM_SHARE_EXCLUSIVE,NULL,&pStm);


                        // add processing here









      return 0;



Note the details of the stat structure in the code snippet above:

Stat              {pwcsName=0x006d3708 “Pictures” type=2 cbSize={…} …} tagSTATSTG

pwcsName          0x006d3708 “Pictures”               wchar_t *

type              2                                   unsigned long

cbSize            {28918}                             _ULARGE_INTEGER

mtime             {dwLowDateTime=0 dwHighDateTime=0 } _FILETIME

ctime             {dwLowDateTime=0 dwHighDateTime=0 } _FILETIME

atime             {dwLowDateTime=0 dwHighDateTime=0 } _FILETIME

grfMode           0                                   unsigned long

grfLocksSupported 0                                   unsigned long

clsid             {GUID_NULL}                         _GUID

grfStateBits      0                                   unsigned long

reserved          0                                   unsigned long


To expand on the preceding code, since you have the length of each picture and the image type, you could read the bytes into a byte array and write them out to disk, or whatever your requirements may entail.


I hope this helps shed some light on parsing Office binary files in general and how you might approach parsing PowerPoint binary files for pictures.

Comments (2)

  1. aperez says:

    Hi Mark,

    Good material about ppt parsing. I found this blog when I started writing some code to interpret compound binary files in order to parse PPT files.

    I’ve done it entirely in Ansi C++ with no OLE or COM components and so far I can extract jpg, bmp images. But I’m struggling with wmf pictures.  Does powerpoint embed this type of picture in compressed or encoded way?

    With jpg pictures I just copy the whole binary data to an output jpg file and it works.

  2. skg says:

    Hello Mark,

    Found your article very helpful. Just like aperez comment, i am having difficulties extracting wmf files.

    is wmf compressed? please advise