Re: PE module: 'not' logic conditions will match on non-PE files - should pe functions first check if file is PE ?

2020-07-01 Thread Wes Hurd
That makes sense, thanks Wesley

I agree the condition should check is_pe
The case where I encountered this from, we had an unwrapped *or* condition
following a *uint16(0) == 0x5a4d and* , which caused that condition by
itself to match on any non-PE
so wrapping the or'ed condition statements in parens fixed it

Be well,

On Wed, Jul 1, 2020 at 3:12 PM Wesley Shields  wrote:

> This is likely due to the change made recently where comparing with
> UNDEFINED values now evaluates to false. It used to evaluate to UNDEFINED.
>
> > But shouldn't pe module conditions check first if the file is a PE
> header or valid base PE, then fail if the file isn't ?
>
> Functions in the pe module do check if they are accessing UNDEFINED fields
> and return UNDEFINED accordingly. This is the behavior of things like
> "pe.exports()" and others. In your case you have a couple of things going
> on...
>
> 1) You are using "pe.section_index()" which will return UNDEFINED on a
> non-PE file. This means you are accessing pe.sections[UNDEFINED] which is
> also UNDEFINED.
>
> 2) You are then accessing the name attribute of an UNDEFINED value which
> is also resulting in an UNDEFINED value.
>
> 3) You end up with 'not UNDEFINED contains ".text"' which as of a somewhat
> recent change evaluates to "not false".
>
> This is all because of a recent change where comparisons (including
> contains) with UNDEFINED values result in false.
>
> It's arguable that this is the right change (and to be honest, I don't
> remember why it was changed) but one thing you can do is prefix your
> condition with "pe.is_pe and ..."
>
> -- WXS
>
> On Jul 1, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
>
> Hi,
>
> Wanted to post here before raising an issue on github project:
>
> *To reproduce:*
> import "pe"
>
> rule pe_on_nonpe
> {
> condition:
>   not pe.sections[pe.section_index(pe.entry_point)].name contains
> ".text"
> }
>
>
>
> Run on non-PE file (e.g. Excel document zip)
> yara pe_on_nonpe.yara excel_doc.xlsx
> The rule matches on non-PE files
>
> But shouldn't pe module conditions check first if the file is a PE header
> or valid base PE, then fail if the file isn't ?
> So *pe.sections* implies the file is PE, does check for valid PE first
>
> Regards,
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to yara-project+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/yara-project/558ba95d-4f7c-4bd7-a8bb-71fab8c97db0o%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to yara-project+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/yara-project/8BDBC9BC-BC20-43F3-86E7-2915154EB077%40atarininja.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/CAOAGZwEk3indmLzGfOjxkaDCSB3Q7XiEbAoyi7OGvQpAQN_fHg%40mail.gmail.com.


Re: PE module: 'not' logic conditions will match on non-PE files - should pe functions first check if file is PE ?

2020-07-01 Thread Wesley Shields
This is likely due to the change made recently where comparing with UNDEFINED 
values now evaluates to false. It used to evaluate to UNDEFINED.

> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ?

Functions in the pe module do check if they are accessing UNDEFINED fields and 
return UNDEFINED accordingly. This is the behavior of things like 
"pe.exports()" and others. In your case you have a couple of things going on...

1) You are using "pe.section_index()" which will return UNDEFINED on a non-PE 
file. This means you are accessing pe.sections[UNDEFINED] which is also 
UNDEFINED.

2) You are then accessing the name attribute of an UNDEFINED value which is 
also resulting in an UNDEFINED value.

3) You end up with 'not UNDEFINED contains ".text"' which as of a somewhat 
recent change evaluates to "not false".

This is all because of a recent change where comparisons (including contains) 
with UNDEFINED values result in false.

It's arguable that this is the right change (and to be honest, I don't remember 
why it was changed) but one thing you can do is prefix your condition with 
"pe.is_pe and ..."

-- WXS

> On Jul 1, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi,
> 
> Wanted to post here before raising an issue on github project:
> 
> To reproduce:
> import "pe"
> 
> rule pe_on_nonpe
> {
> condition:
>   not pe.sections[pe.section_index(pe.entry_point)].name contains ".text"
> }
> 
> 
> 
> Run on non-PE file (e.g. Excel document zip)
> yara pe_on_nonpe.yara excel_doc.xlsx
> The rule matches on non-PE files
> 
> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ? 
> So pe.sections implies the file is PE, does check for valid PE first 
> 
> Regards,
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/558ba95d-4f7c-4bd7-a8bb-71fab8c97db0o%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/8BDBC9BC-BC20-43F3-86E7-2915154EB077%40atarininja.org.