Womp womp. This is an area have I no familiarity with and exhausted my attempts. As time permits, I’d like to revisit this and dig more into the Messaging Application Programing Interface (MAPI) API.
While I wasn’t able to get any points for this question, I took the opportunity to take few additional (unlimited) guesses during week 3.
Using MFCMAPI.x64.exe, I can preview the properties the .msg file.
After a handful of guesses, 0x001A for PR_MESSAGE_CLASS, is the correct answer. But why?
That’s nice to know, but what causes the envelope to show up? Google: “pr_message_class envelope”
With Outlook open and OutlookSpy installed, I open the email to check it out and edit it. OutlookSpy | IMessage | GetProps.
After I edited the property to a known value, “IPM.Note,” the envelope disappears.
I’m not clear what would cause that in a typical environment. I gather that the key here is if you recognize what is “normal”, you’d be able to see that value standout as an anomaly.
I hashed the contents of the decompressed .pdf for my first attempt. That was wrong.
After reading the contents of the email, I find there’s an apparent problem with the .zip file. The comment about the file’s first 24 bytes appeared to be a hint. When decompressing the file, the .pdf is not readable. Ah, okay. I’m tracking now.
I started with comparing the corrupt .zip file, and a known good .zip file. I looked for 0x00 values within the first 24 bytes. For simplicity, I used the evidence object already provided. I selected View | Synchronize & Compare in X-Ways Forensics. I noted that the offsets 18-21 might be different.
What sort of structure does a .zip typical have? Florian Buchholz has documentation on that, which notes that offsets 18-21 represent the compressed size of the file in little-endian.
GOAT.zip is 369,547 bytes. What’s that in hex (little-endian)? Using the programmer calculator, it’s 0x8BA305. I’ll need to try it by editing the file with a hex editor.
I already have the original evidence object saved locally to open it in WinHex. But if I didn’t, I would I select Recovery/Copy from the Directory Browser.
With GOAT.zip open in WinHex, I make the change to offsets 18 and 19.
After adding the edited file back into XWF, I’m now able to preview the file, GOAT.pdf.
Knowing that I’m able to preview it, I just have to hash the file.
From the Directory Browser, I can use the context menu to take a refined volume snapshot to compute the MD5 hash.
After a quick hash calculation, I can now copy it from the context menu.