Create carver for eMule preferences.dat files

[fmpfeifer]

According to Lange et al. (Identification of Forensic Artifacts in eMule), the eMule UserHash (also known as the GUID) is not entirely random, as the 6th and 15th bytes are fixed (0E and 6F, respectively).
We can leverage this information to create a carver for preferences.dat files. Additional information from the eMule source code can also be used to identify more bytes in the file that can serve as a signature for it.

[fmpfeifer]

It can be done simply by creating the signatures in the CarverConfig.xml file. I'm finishing the tests, but it seems to be working well.
Should I add it to the main CarverConfig.xml, or only to the pedo profile?

[fmpfeifer]

One more piece of information:
I was also able to create a carver for the UserHash not only in the preferences.dat file, but also in a hello packet from the eDonkey protocol (the raw bytes of the packet can be present in memory and saved to pagefile.sys or hiberfil.sys). Using this approach, I was able to recover the UserHash of a suspect who had deleted the eMule application before the computer seizure.

However, these packets can be both sent and received by the user, so there is no guarantee that the UserHash found using this method actually belongs to the suspect—it could belong to any user who happened to be connected to them and sent a hello packet.

Do you think it’s worthwhile to include this carver as well?

[lfcnassif]

It can be done simply by creating the signatures in the CarverConfig.xml file. I'm finishing the tests, but it seems to be working well.
Should I add it to the main CarverConfig.xml, or only to the pedo profile?

AFAIK, internally the Carver module would create 2 signatures of only 1 byte, scan for them and check if distance between hits are 9 bytes. Since internal signatures would be just 1 byte length, I think it could result in tons of false positives and could cause an important permorfance impact. It can also increase the memory usage to store temporary hits, it might be another problem.

Maybe a specific carver, like KnowMetCarver would work better, not sure.

[fmpfeifer]

It can be done simply by creating the signatures in the CarverConfig.xml file. I'm finishing the tests, but it seems to be working well.
Should I add it to the main CarverConfig.xml, or only to the pedo profile?

AFAIK, internally the Carver module would create 2 signatures of only 1 byte, scan for them and check if distance between hits are 9 bytes. Since internal signatures would be just 1 byte length, I think it could result in tons of false positives and could cause an important permorfance impact. I can also increase the memory usage to store temporary hits, it might be another problem.

Maybe a specific carver, like KnowMetCarver would work better, not sure.

oh, i see. the signature I created is the following:
\14?????\0E????????\6F?\2C\00\00\00?\00\00\00?\00\00\00??????????????????\00\00??\00\00??\00\00??\00\00

[fmpfeifer]

\14 - version. All found are 20 (hexa 14)
?????\0E????????\6F? - userhash - 6th and 15th bytes are fixed
\2C\00\00\00 - Size of the WINDOWPLACEMENT structure
?\00\00\00 - Flags in WINDOWPLACEMENT structure
?\00\00\00 - showCmd in WINDOWPLACEMENT structure
???????????????? - 2xPOINT Structure - Usually filled with \FF, but not guaranteed
??\00\00 - 4x - the coordinates of the corner of the screen when restored and minimized. the number is in UINT format, but should fit in USHORT, so the 16 higher bits (little endian) are zeroed

[fmpfeifer]

But if the carver is searching for 1 byte signatures, it could indeed have a big impact on performance.
I'll try to create a custom carver

[lfcnassif]

But if the carver is searching for 1 byte signatures, it could indeed have a big impact on performance.
I'll try to create a custom carver

Theoretically yes. But I would suggest running the new configured Carver on a large case and compare running time with and without it. And ideally also monitor the heap usage with JVisualVM, with and without it.

[fmpfeifer]

I tested it on a large case over the weekend, and indeed it turned out to be too slow.
So I followed the suggestion of creating a new task similar to the existing KnownMetCarveTask. It worked well and was very simple to implement by following the KnownMetCarveTask model.

However, before submitting the PR, I realized that this carver could actually be merged into KnownMetCarveTask instead of creating a new one—maybe renaming it to EmuleArtifactCarveTask. This way, we can avoid reading through the inputStream twice.

I think merging it should be straightforward, since all the carved files have different first bytes.

What do you thing @lfcnassif and @wladimirleite ?

[wladimirleite]

However, before submitting the PR, I realized that this carver could actually be merged into KnownMetCarveTask instead of creating a new one—maybe renaming it to EmuleArtifactCarveTask. This way, we can avoid reading through the inputStream twice.

I think merging it should be straightforward, since all the carved files have different first bytes.

What do you thing @lfcnassif and @wladimirleite ?

I think that would be the best strategy, to avoid duplicated reading as you mentioned.

[lfcnassif]

Agreed.