Re: [sleuthkit-users] Encryption flag issue

[Luís F. N. <lfc...@gm...>]

Hi Brian,

If you do not fill Metadata.RESOURCE_NAME_KEY, only content will be used.
But I do not recommend that, because there are many mimetypes detected
based only on filename/extension.

This logic is in MimeTypes class, unfortunatelly it is final. Will talk to
Tika colleagues to see if we can make that configurable, so filename would
be used only when there is no signature registered for the mimetype.

Regards,
Luis

Em sex, 22 de mar de 2019 às 15:55, Brian Carrier <ca...@sl...>
escreveu:

> Do you know a way to turn off falling back to the extension?  I don't see
> anything obvious in the docs.
>
> On Thu, Mar 21, 2019 at 11:46 PM Luís Filipe Nassif <lfc...@gm...>
> wrote:
>
>> Default Tika behaviour is to detect mimetypes based on known signatures
>> or structures (looking inside zip and ole containers). If no known
>> signature/structure is found, Tika falls back to name/file extension
>> detection.
>>
>> Hope this helps,
>>
>> Regards,
>> Luis Nassif
>>
>> Em qui, 21 de mar de 2019 às 11:48, Brian Carrier <ca...@sl...>
>> escreveu:
>>
>>> Interesting. The MIME type is what is throwing it off.  Our algorithm
>>> will only flag items that do not have a known type because videos and such
>>> can be big and random.
>>>
>>> We use Apache Tika for file type detection and we recently observed a
>>> file that had an incorrect type applied and Tika seemed to have made the
>>> decision based on the file extension.  I wonder if that happened here too.
>>> We'll try to recreate this.
>>>
>>> In the mean time, can you rename the file to something like ".dat" and
>>> see if you get the same results.
>>>
>>>
>>>
>>> On Thu, Mar 21, 2019 at 7:15 AM Søren Berggreen <shb...@gm...>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> 1) It says application/x-msdownload.
>>>>
>>>> 3) I tried with lower settings, but still no luck.
>>>>
>>>> Best regards
>>>> Soren Berggreen
>>>>
>>>>
>>>> On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...>
>>>> wrote:
>>>>
>>>>> Hi Soren,
>>>>>
>>>>> 1) If you navigate to the file in Autopsy, select it, and go to the
>>>>> File Metadata tab, then what MIME type does it say the file is?   I'd
>>>>> assume application/octet-stream.
>>>>>
>>>>> 2) The default behavior for the extension mismatch module is to only
>>>>> focus on hidden pictures, videos, executables, etc. So, if the encrypted
>>>>> volume had a type of application/octet-stream, then it is not surprising
>>>>> that it wasn't flagged.   The module is flagging known content types (such
>>>>> as JPEG) that have been renamed.
>>>>>
>>>>> 3) The Encryption Detection module does have a setting about entropy
>>>>> levels. I believe the default value is 7.5.  If you change it to 7.0 and
>>>>> re-run ingest then does it find the file?
>>>>>
>>>>> thanks,
>>>>> brian
>>>>>
>>>>>
>>>>> On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I've got this issue that I haven't been able to solve:
>>>>>>
>>>>>> Autopsy 4.10.0 on Windows 10 Pro
>>>>>>
>>>>>> Problem:
>>>>>> A known encrypted file is not flagged when running the Encryption
>>>>>> Detection Module.
>>>>>>
>>>>>> Secondary problem:
>>>>>> The encrypted file is saved as a .dll file, but is not flagged when
>>>>>> running the Extension Mismatch Detector Module.
>>>>>>
>>>>>> Pre:
>>>>>> An encrypted container was created using Veracrypt. The size of the
>>>>>> container was set to 100MB. Hash sha512, encryption serpent, filesystem
>>>>>> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in
>>>>>> folder "C:\Program Files\Oracle\VirtualBox\x86".
>>>>>>
>>>>>> The forensic image on where the container is located, was also tested
>>>>>> using X-Ways and EnCase, and both tools flag the container as encrypted.
>>>>>>
>>>>>> Best regards
>>>>>> Soren Berggreen
>>>>>> _______________________________________________
>>>>>> sleuthkit-users mailing list
>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>>> http://www.sleuthkit.org
>>>>>>
>>>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>>>
>>