the resulting information is mainly used for indicative findings.It seems that the email content in the fragment nsf file is compressed,so directly utilizing string search can not find what i am looking for.It is all about a hard drive of 200GB size
I had a defence job many years back where the prosecution couldn't find some deleted received emails that our client had sent he had just forwarded - i.e. they had the forwarded/sent message but not the message he had received
The emails where in AOL PFC's and it seemed that the received emails were compressed but the sent/forwarded emails where not. It took a little effort to write a tool that could identify an AOL compression header and then search unallocated for the header and decompress the data to find the emails our client had received and forwarded.
As emails need to stand alone (i.e. each email is *likely* compressed as an individual item) I would expect that this approach could be utilised with nsf files (it's many many years since I have played with one of these though so I could be mistaken )
Did anything ever come of this discussion? I'm about to start working on a case involving Notes right now, and am curious as to exactly how it's compressing the emails. I would imagine if the algorithm were properly understood, it might be possible to carve out individual compressed email message chunks and decompress them.
Thoughts on this anyone?
Thanks
John
Did anything ever come of this discussion?
….
Thoughts on this anyone?
Have you actually read the nice PDF about the format by joachimm?
It is currently here
https://
jaclaz
hi i think your mail file is Encrypted Please Open a Suitable versions .
OK,
So I've been perusing Mr. Metz's PDF document, but what I'm finding in my sample NSF files doesn't precisely match up with what he's documented.
I'd appreciate any commentary from others who are knowledgeable regarding the NSF format.
Specifically, I've done keyword searches (for the 16-byte Notes UNID of the email message, appropriately formatted) to identify the place where an email that is correctly extracted by the current version of FTK appears to be actually stored.
There were a few other hits for the UNID, but I eliminated each by determining that the surrounding data in each appeared to be various kinds of table, rather than other encoded data.
The data at the one location which appeared likely to contain the encoded email was formatted similarly to what Metz described in the PDF as 'Non-summary note item data; (12.2.3 in the PDF).
It started with a 2-byte signature, 0x0010, followed immediately by a 4-byte size that matched with the apparent extent of the encoded data which made up the bulk of the record. After this appeared 4 bytes which according to the PDF, and assuming this is actually a non-summary data structure, would be a RRV identifier.
Following the possible RRV identifier was where the 16-byte UNID I had searched for appeared. According to the PDF, this would be two 8-byte Notes date/time structures, which are respectively used as a 'File Identifier', and 'Note Identifier'. In this case (and I validated it in a 2nd similar instance), the 'File Identifier' portion of the UNID did not encode a valid Notes date.
After the UNID followed a 4-byte 'Sequence Number' (1 or 3 in my two examples), then an 8-byte 'Sequence Date/Time' (valid Notes date)
Following this, the PDF would lead me to expect 'Note header data', which is described in a different section. However what actually appears differs substantially from what's described in section 12.1 of the PDF, which is where it purports to describe the data structure of a Note Header.
Where a Note Header is supposed to begin with a two-byte signature of 0x0004, what I actually observe is another Notes Time structure, followed by a repeat of the same size value mentioned above.
After this occurs another hundred bytes or so of what I believe to be headers, followed by what looks to me like some kind of compressed data. At the very end of the record is another 170 odd bytes of header data, ending in two more valid Notes dates. I say 'header' just because of the look of the data. Unlike the portion I believe to be compressed message data, it contains quite a few instances of 0x00.
Thoughts?
John
One more data point. I just realized that the 'RRV Identifier' is actually the number extracted by FTK as the 'Note ID' of the email message.
John
I have not touched Notes in a while so I'll have to revisit my documentation to say anything sensible about it.
Don't consider my working document as the only authoritative source of the format. I know it might be one of the few ones out there. The document is based on the analysis I did on the format at the time, but it is based on a limited set of samples. With most formats the challenges are in the edge cases.
NSF is a very feature rich format and I'd noticed that different versions might be formatted differently
If you (and others) can share the hexdump of the part that does not add up to the documentation or share the file if possible I can have a more detailed look.
Note that my time is very limited at the moment.
A couple of additional questions for the community
1 Is there a way to tell whether or not Notes was set to save copies of outgoing email in the ‘Sent’ folder? And maybe if/when this setting was changed? I’ve got a case with an empty ‘Sent’ folder, and I’m curious as to whether it was intentionally cleaned out, or was not set to retain copies all along.
2 If a user has a Notes email database on their laptop, is that just used for local archiving, or would that database typically have its contents synchronized with the user’s database on the Notes server? If the answer depends on the configuration, how would you tell the difference?
Thanks
John