There seems to be a problem with traversing the section

[helloobaby]

import "pe"

rule have_another_pe 
{
    strings:
        $a = { 4D 5A 90 00 }
    condition:
        for any s in pe.sections:(
            $a
        )
}

Yara output

have_another_pe C:\Windows\System32\ntoskrnl.exe
0x0:$a: 4D 5A 90 00

Problem: Why do I traverse the section, yara will match the dos header?

[wxsBSD]

I'm not sure I am understanding your question here, but I think you're asking why the for any i in ... loop is evaluated when $a has already matched and the loop is not operating on $a in any meaningful way? That is because the compiler doesn't know that you are asking it for something which can be short-circuited. Of course, you and I know that the for loop is unnecessary and can just be replaced with $a but the compiler doesn't know that and teaching it that would be quite cumbersome and error prone.

[helloobaby]

Sorry for uploading the wrong code(already modified). I want to search "4D 5A 90 00" pattern in ".text" ".data" and etc section. but i get matched at dos header(IMAGE_DOS_HEADER) (offset 0)

[wxsBSD]

Because $a did match there. Strings are searched for everywhere in the file, then the condition is evaluated. If the rule matches then all string matches are listed when you use the -s option, regardless of where they are in the file or what you do with them in the condition (with some exceptions, see below). This is just how YARA works.

If you want to match the rule only if `$a is in one of the sections you could do:

for any section in pe.sections: ($a in (section.raw_data_offset..section.raw_data_offset + section.raw_data_size))

Please note that if $a matches outside of a section AND inside of it, the rule will match (because it matched inside the section) but you will still see it matched outside of the section in the -s output.

Anytime this comes up I encourage people to think of YARA as a two-step process. Step 1 is just searching for all the patterns listed in the rules, regardless of where they are in the file (with a couple of small exceptions). Step 2 is to evaluate the conditions in each rule. In most cases the string you are searching for is independent of the condition in which it is used. That is, the search algorithm has no idea they you only want it within PE sections so it has no option but to search for it everywhere. The major exception to this is when you use $a at 0 constructs, which allow the string search algorithm to essentially limit the search to that specific offset, thus you won't get any extra matches in the -s output in this case.

[helloobaby]

That works. thank you very much for your patience

[helloobaby]

I found another very strange problem. I basically have no problem with the rules you provided, but when matching some debug compiled exe, it will still match outside the section, and release compilation is fine.

Details:

rule carved_pefiles
{
    meta:
        author = "sbb"
    strings:
        $a = {4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00}
    condition:
        pe.is_pe and
        for any section in pe.sections: ($a in (section.raw_data_offset..section.raw_data_offset + section.raw_data_size))
}

YARA Output:

PS D:\vs-code\yara_rules> .\yara64.exe .\malware.yar D:\vs-code\direct_system_call\x64\Release\direct_system_call.exe

PS D:\vs-code\yara_rules> .\yara64.exe .\malware.yar D:\vs-code\direct_system_call\x64\Debug\direct_system_call.exe
carved_pefiles D:\vs-code\direct_system_call\x64\Debug\direct_system_call.exe

with '-s' option

PS D:\vs-code\yara_rules> .\yara64.exe .\malware.yar D:\vs-code\direct_system_call\x64\Debug\direct_system_call.exe -s
carved_pefiles D:\vs-code\direct_system_call\x64\Debug\direct_system_call.exe
0x0:$a: 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00
PS D:\vs-code\yara_rules>

Sorry to bother you again, but I am very confused(this pe file (direct_system_call.exe) should not match the rules 'carved_pefiles ' )

[wxsBSD]

Do you have the section information from the debug PE? My theory is there is a weird section in there that is covering the whole file.

[helloobaby]

do you need the whole exe or source code?

[wxsBSD]

The .textbss section starts at offset 0 and is 0 bytes, so the condition is basically "$a in (0..0)". This is a true expression for your file.

This should be turned into a warning for the times when we can statically detect that in the compiler, but that won't help for your case where those values aren't known until runtime.

[helloobaby]

yes,thank u very much