Can I access DensityLists, FreeMaps or AMaps from within the PST SDK ?

Feb 14, 2013 at 12:50 PM
I searched for the respective fields into the pstdsk and disk structures. In the SVN version I see some fields but in my downloaded library code I don't see them (like in ndb/allocation.h which in my library version is missing).

Can you please help me with this ?

Thanks in advance !
Feb 15, 2013 at 10:35 AM
Ok, I tried to access the AMaps as I understand from the PST File-Format spec, from address 0x4400, every 496 * 8 * 64 B each AMap, with first byte auto-mapped, and each bit representing the availability (value 0) or unavaillability (value 1) or the next 64 B block, starting with block 8 (512 B = onae page = 8 blocks are reserved for the current AMap). I've made a small C++ app that is able to securely wipe those blocks that the AMap specifies as being unallocated, but doing this corrupts the PST file and I don't understand why.

Can anyone help me?

I also managed to read the "fAmapValid" flag which is telling me that the AMaps are in consistent state. So I don't get it, although for reaching out this flag I discovered that the specs I was using for the file format (2012 and 2013 versions) are wrong in respective with my PST file (generated by Outlook 2007) as it specifies an additional Reserved block in the header (8 bytes) in before the root block (which contains the flag) block that in my case it doesn't exist. So are there any incompatibilities among specifying AMaps too ?
IS there something wrong with the way I access the AMaps ? Are the AMaps crypted too ?

Please, is there anyone there? I really need a quick answer on this. Feel free to question me if there is something you don't understand in my problem specification, but I really need your help guys !

Thanks !
Feb 15, 2013 at 4:13 PM

It sounds like you're on the right track. My best guess it that you're not calculating the proper offset of the next Amap page (I do recall the first one is at 0x4400). When you read the AMap page off of disk, verify that it has the correct CRC and page type (from the Page trailer). The disk.h file in PSTSDK should help with calculating the offsets between Amap pages.

And you definitely can't trust the contents of the fAMapValid flag (to do a secure wipe on the unallocated pages) unless the fAmapvalid flag is set.

Amap pages are not crypted.

Good luck!
Feb 15, 2013 at 5:47 PM
Thank you terrymah !

Update: I've confirmed that I was reading the AMaps corectly (with the page CRC and with the free AMap space field from the header). For sure and no doubt I read the AMaps corectly. But somehow Outlook still screams he doesn't like my file.
As far as I know CRC only affects some PST file sections (like the header, the root etc.) and the allocated blocks. I don't see if there would be a CRC for 64B blocks that are not allocated. Is this correct ? And if so, I'm out of ideas !

Can you please help me with some ideas ?

Thanks !