I am analyzing two computers with eMule installed in a case of videos distribution of child sexual abuse.
I want to ask some questions about the file known.met.
I analyze the known.met files with eMule MET Viewer. Particularly I have doubts about two reported dates "Last Posted (UTC)" and "Last Shared (UTC)".
In Artifact Reference of AXIOM I found the definition of these dates.
Last Posted the date and time when the file was posted or should be reposted on the KAD network.
Last Shared the time when the file was last shared.
In my tests "Last Posted" matches the definition. If the file is still shared the date is loaded only when there is a connection to the KAD network. But, if the file has insufficient sources on the KAD network, the file will not be posted (in order to prevent flooding). Instead the file is given a time and date stamp (“reposting time”) which is actual time + 5 hours (GMT).
“Last Shared (UTC)" is completed with the date on which eMule is opened even if it is not connected to any network and the file has never been shared. In this case it does not match the definition.
I would like to know if someone has analyzed when the “Last Shared (UTC)” field is completed and its meaning.
Regarding this "if the file has insufficient sources on the KAD network, the file will not be posted (in order to prevent flooding). Instead the file is given a time and date stamp (“reposting time”) which is actual time + 5 hours (GMT)."
I found this explanation in
Any suggestions or comments on this topic?
I'm afraid it's been donkeys years since I've had to deal with this sort of case (and therefore this program) so I can't be of much use. Apologies for the deliberate pun wink
There was this thread previously on FF if you've not already seen it https://www.forensicfocus.com/Forums/viewtopic/t=13245/
Perhaps it's a version-related issue with the known.met file, that the thread above flags as a possible issue, and perhaps the parser only parses one type properly.
In situations like yours I think you'd have to get stuck in and do some testing yourself and try to replicate what you're seeing or not seeing? (using the same version of the eMule / settings that you have in your case and then trying various combinations of things to try to shed some light on it)
At least then you'd have some basis for your conclusions when reporting.
I suppose what's perhaps the most relevant thing, is you've shown (in your configuration at least) that the field isn't reliable for indicating sharing (assuming your known.met tool is working properly), based on your testing, assuming there's no issue there. Perhaps you should therefore focus more on determining, via testing, whether the other fields appear a more reliable indication of sharing (ie the upload/download bytes) as well as checking whether the known.met parser isn't the issue.