-
Notifications
You must be signed in to change notification settings - Fork 534
Add convenience method for YaraScanner #1859
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Add convenience method for YaraScanner #1859
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fairly innocuous, but to avoid code duplication, I'd probably make use of it whenever text is being compiled into a pattern, so use it in get_rule
as well. You'd need to check if there's a subtle difference in output between yara.compile(source=...)
and yara.compile(sources=...)
but I don't think that should be too catastrophic for people to cope with.
@@ -101,6 +101,13 @@ def from_file(cls, filepath): | |||
return yara_x.compile(fp.read().decode()) | |||
return yara.compile(file=fp) | |||
|
|||
@classmethod | |||
def from_text(cls, rule): | |||
formatted_rule = rule.replace("\n", "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we stripping all new line characters, and is there any situation in which that could change the meaning of the rule?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also feels like get_rule
could be modified to call this after wrapping its parameter into simple rule text?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New line stripping: good point! The docs of yara-python contains an example with a single line rule hence I replaced the newlines. I tested it with ~20 rules, and the newline can be included without any problems. I removed the replace
line of code.
The source
vs sources
thing: the main difference is the namespacing. Theoretically we could check whether the given rule is a string or a dict and use source
and sources
accordingly. Don't prefer that though because of it's implicitness. The function name from_text
is also clear in that it requires text, and not a dict.
The get_rule
currently uses namespaces while from_text
does not. I don't think it'd be wise to change it to use from_text
because that would result in a backwards incompatible change. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, fair enough. Looks good then, thanks! 5:)
Oh, |
Also, the type hinting uses |
This convenience method makes it easier to use the YaraScanner with a Python defined YARA rule. This makes one off, single file plugins easier to make because one can include the YARA rule directly in Python instead of having to include the rule in a separate YARA file. I.e.: