Skip to content
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

Update to Yara 4.3 #6

Merged
merged 32 commits into from
Mar 5, 2023
Merged

Update to Yara 4.3 #6

merged 32 commits into from
Mar 5, 2023

Conversation

vthib
Copy link
Owner

@vthib vthib commented Dec 27, 2022

This is a work in progress, as Yara 4.3 is not out yet.

Most of the small work has been done, what's left is:

@vthib vthib self-assigned this Dec 27, 2022
@plusvic
Copy link

plusvic commented Dec 29, 2022

@vthib, by following a link in YARA's repository I landed here and discovered this project. I don't know if you have seen https://github.com/VirusTotal/yara-x, but the goals are very similar: a complete implementation of YARA in Rust, that solves some of the pain points experienced by YARA users (like slow rules that should be actually fast) and developers (like the parser tightly coupled with YARA itself that disallows its reuse).

The approach however is different. YARA-X converts rule conditions into WebAssembly code, that in turns gets translated into native code. This makes conditions that rely heavily on loops much faster. The goal is that condition evaluation is 10x faster than the existing YARA on average. I see that you seem to have experience in Rust (more than myself, I'm gradually learning Rust with the YARA-X project), so if you would like to contribute to YARA-X in some way you are really welcomed. The project is still immature and unstable, but I've made a lot of progress already, and have implemented most of the condition evaluation logic.

@vthib vthib force-pushed the yara-4.3 branch 2 times, most recently from 8ada5b4 to ba6794e Compare January 2, 2023 13:25
@vthib vthib force-pushed the yara-4.3 branch 3 times, most recently from decde38 to a5bd867 Compare January 8, 2023 12:23
@vthib
Copy link
Owner Author

vthib commented Jan 9, 2023

So this is failing only on linux32, and it took me longer than expected to understand why. Running boreal-cli has no issues, running the tests on linux32 does give invalid values for not_before and not_after fields in the authenticode certificates.
Turns out, this is a linker issue. When linking the final binary, there are two libraries that have functions with the same names:

  • libyara.a version 4.3, compiled through yara-rust, with the new authenticode library
  • libauthenticode.a, compiled through the authenticode-parser crate, with this authenticode library as well.

So the linker can pick any of those two and we can't control it.

  • For boreal-cli, this is not an issue, we do not link against yara, so there is a single solution.
  • For the tests, we link against yara to check conformance, hence the conflict. This is all fine if both libraries have the same code, but because of this commit: vthib/authenticode-parser-1@fd91356, the objects do not have the same size. We end up linking against the yara authenticode functions, but use the bindings on the authenticode-parser version. Those types differ only on linux32 (time_t = 32 bits != int64_t), causing the crashes.

Best solutions is probably to rename all of the functions in the authenticode-parser crate to avoid conflicting with yara symbols... Fun.

@vthib vthib force-pushed the yara-4.3 branch 2 times, most recently from 75ad1da to a473687 Compare January 15, 2023 18:38
@vthib vthib force-pushed the yara-4.3 branch 3 times, most recently from a9e20d2 to c899d72 Compare March 2, 2023 20:40
vthib added 19 commits March 5, 2023 15:31
Update boreal-object fork to handle this case.
Import binaries for the yara PR and add coverage tests on them.
Do not return undefined in the "#var in (from..to)" expression when the
range bounds are weird. Instead, act as if the values are valid.
This avoids the use of the const version of Mutex::new, which is not
available in rust 1.62.
The particularity is that this option acts as its own mode: if given, it
will print the names and exit, so the required arguments (rules & input)
are not required if this option is specified.

This was not trivial to find how to express this with clap, but the
required_unless_present seems to work.
@vthib vthib merged commit 384b3ad into master Mar 5, 2023
@vthib vthib deleted the yara-4.3 branch March 5, 2023 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants