I think there's some confusion on versions. As I mentioned in my original post, this happened to me running the latest release of both yara and yara-python, 4.0.2
*/usr/local/Cellar/yara/4.0.2/* */usr/local/lib/python3.7/site-packages/yara.cpython-37m-darwin.so <http://yara.cpython-37m-darwin.so> /usr/local/lib/python3.7/site-packages/yara_python-4.0.2.dist-info/** yara.cpython-37m-darwin.so: 09309970dfee080222ae348046e5a62117811371a5fbece5e67b8718a5c2b247 It was last upgraded from 4.0.1 My colleague who had yara-python 3.10 didn't run into this issue locally either, so I'm wondering if it's an issue with the latest releases. Wesley - I agree the non-match under yara is the expected behaviour. Thanks, On Wed, Jul 8, 2020 at 3:57 AM Víctor Manuel Álvarez García < [email protected]> wrote: > This issue is probably related to this change: > https://github.com/VirusTotal/yara/commit/b7da5d2835cc4cf8a15027da30265addab1a4be5 > > Old versions of YARA had a weird behaviour when the NOT operator was used > in conjunction with MATCHES or CONTAINS on undefined values. Your old > version of yara-python has the bug while the command-line tool is more > recent and does not have it. The strange thing is that PIP tells you that > you are up-to-date with version 3.10.0, maybe you have both version 3.10.0 > and 4.0.2 but Python is loading version 3.10.0 instead of the most recent > version. Dependencies in Python are really painful sometimes ( > https://xkcd.com/1987/) > > On Wed, Jul 8, 2020 at 3:32 AM Wesley Shields <[email protected]> wrote: > >> 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, >> especially if you have an older install of libyara laying around. It's >> almost as if it isn't picking up the bundled version of yara and is instead >> falling back to whatever you have laying around. You commented out the >> printing of the version in your python snippet, but just to confirm that is >> printing the correct version of yara? >> >> To be clear, I think this is a local problem and your evaluation is >> possibly incorrect. I think the bug is that it DOES match under yara-python >> when it should not. It not matching when running yara from the command line >> is the correct behavior (I think). >> >> -- WXS >> >> On Jul 7, 2020, at 2:10 PM, Wes Hurd <[email protected]> wrote: >> >> 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 yara binary directly. >> >> Running on this PE file: >> https://www.virustotal.com/gui/file/154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8/details >> >> "test_odd_pe_py_match.yara": >> 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 pe.sections[pe.section_index(pe.entry_point)].name >> contains ".text")) >> } >> >> >> >> Python : >> import yara >> #print(yara.__version__) >> >> try: >> scan = yara.compile("./test_odd_pe_py_match.yara") >> except yara.Error as e: >> print("YARA compile error:", e) >> >> matches = scan.match(filepath= >> "154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8.exe") >> print(matches) >> >> [Odd_PE_Entry_Point] >> >> >> >> yara bin: >> $ yara test_odd_pe_py_match.yara >> 154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8.exe >> >> $ >> No matches >> >> >> Can someone tell what's going on here ? >> It seems to me there is some sort of either rule parsing bug under >> python, or race condition that causes the python run to match when the >> binary doesn't. >> >> Thanks, >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/yara-project/48c4b198-182b-4f28-aecd-90db120ef1c8o%40googlegroups.com >> <https://groups.google.com/d/msgid/yara-project/48c4b198-182b-4f28-aecd-90db120ef1c8o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/yara-project/4BA5B724-FCC0-4854-BCCD-5D06F2D150F2%40atarininja.org >> <https://groups.google.com/d/msgid/yara-project/4BA5B724-FCC0-4854-BCCD-5D06F2D150F2%40atarininja.org?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/yara-project/CAD7Y4L4WCpQ6YrvvWPrmAK6ABZ0nh%3D6N0MOewkHHfL%2B5M9vpaQ%40mail.gmail.com > <https://groups.google.com/d/msgid/yara-project/CAD7Y4L4WCpQ6YrvvWPrmAK6ABZ0nh%3D6N0MOewkHHfL%2B5M9vpaQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/yara-project/CAOAGZwEE1U%2BDhXPUnS%3DeDuWQz0fRE1PEsC%2BiRKs%3DHdKH04bxfQ%40mail.gmail.com.
