-
Notifications
You must be signed in to change notification settings - Fork 85
feat: implement dex
module
#458
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: main
Are you sure you want to change the base?
Conversation
…for preserving order in strings
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
optional uint32 file_size = 5; | ||
optional uint32 header_size = 6 [(yara.field_options).fmt = "x"]; | ||
optional uint32 endian_tag = 7 [(yara.field_options).fmt = "x"]; | ||
optional uint32 link_size = 8; |
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.
Are all these fields xxxx_size
and xxxx_off
really useful? They look like the offset and size of certain sections within the files, are but I would avoid exposing to much data in the module of that data is seldom used in real-life YARA rules.
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.
I'm not sure about deleting these parameters, because sometimes you can build a rule on them.
In my opinion, we shouldn't delete this information, because in fact it is the header of the dex file and it is better to reflect it completely.
@plusvic Hi, there are a lot of clippy errors in the pipeline that are not related to my code (or any my changes) It's better to fix them in the master, and then merge them into this branch, rather than the other way around. |
Hi, I have implemented the
dex
module.The current version is incompatible with the old version, because in that implementation there were not very convenient methods and names of exported variables.
What has been changed:
checksum
for computing adler-32 checksum;signature
for computing sha-1 signature;contains_strings
,contains_methods
,contains_classes
- honestly, I doubt their usefulness, but I decided to leave them, because binary search is used under the hood, since the strings are guaranteed to be sorted by the format itself;has_method_string
,has_method_and_class_string
,has_method_regexp
,has_method_and_class_regexp
,has_class_string
,has_class_regexp
(as far as I can see on github, no one used them anyway); And in practice, quite useless calls;dex
module;Fuzzing testing was started locally, all errors were fixed, but I do not exclude that something else will be revealed during a long run.
Since the most difficult thing in programming is to come up with a name for variables, if there are suggestions about names in proto, then I'm ready for discussion.