I can't replicate this - it does not match on 4.0.2 on my system. There is no
rule parsing bug here - the same C code is used when compiling rules using yara
on the command line or via python. I've had a couple of people tell me
something weird is going on when using pip to install yara-python,
I don't think fullword makes sense here, given that the base64 modifiers are
meant to work when the string you're searching for is embedded anywhere in a
base64 encoded string. This requires that it strip some leading and trailing
bytes. If you want to find it without this behavior just put the
Hi again.
Sorry, I now see you mentioned you're using yara-python 4.0.2 (pip). Well,
I don't know why but pip3 says my 3.10.0 version is up to date. I'm not
that familiar with yara-python (I don't know if it follows yara version
numbers for instance). I couldn't install this 4.0.2 version to
Hi,
I couldn't reproduce it here.
$ cat test_odd_pe_py_match.yara
import "pe"
rule Odd_PE_Entry_Point
{
condition:
uint16(0) == 0x5a4d and
((pe.entry_point >= pe.sections[pe.number_of_sections -
1].raw_data_offset) or (not
Hi again,
I'm wondering if there is a way to match Base64 strings only when they are
'fullword', standalone.
For example:
rule base64_Example
{
strings:
$s = "setsockopt" base64 base64wide // c2V0c29ja29wdA==
condition:
$s
}
This rule will match anything containing the string
Hi,
This is running with the following versions on macOS 10.14.6:
*yara 4.0.2 homebrew*
*yara-python 4.0.2 (pip) *
*Python 3.7.7*
I'm having a really weird case where a rule using pe module is unexpectedly
matching certain files when run under yara-python , but not matching if
running the
