Re: [sleuthkit-users] Encryption flag issue

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

Actually it is not a fall back mechanism, it is a mimetype refinement
strategy.

Em sáb, 23 de mar de 2019 às 14:57, Luís Filipe Nassif <lfc...@gm...>
escreveu:

> 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
>>>>
>>>