search

kevoreilly / capemon

capemon: CAPE's monitor
GNU General Public License v3.0
100 stars 49 forks source link

changing project properties to make them fit better #76

Closed nblog closed 7 months ago

nblog commented 9 months ago
  1. Replace with a reference to the "bson" project.
  2. Remove "libyara", provided by nuget (https://www.nuget.org/packages/Microsoft.O365.Security.Native.Libyara/)
  3. switch "bson" and "loader" projects to v141_xp(Part of the configuration is v141_xp, but it's messy)
kevoreilly commented 8 months ago

Thank you for the pull request. The idea to switch to nuget libyara is interesting - what motivated you to do this? Unfortunately their build is 9 months old so it's too outdated to replace the manually built one I'm afraid.

nblog commented 8 months ago

This repository is sourced from Microsoft and is guaranteed upstream, both in terms of usability and stability.

Another main reason is that the linking method uses lib\libyaraXX.lib, which can lead to inconsistencies between the version of the runtime library and the yara-lib runtime library due to different versions of VS.

kevoreilly commented 8 months ago

That sounds great - by guaranteed upstream you mean it is the latest release (4.5.0) or even the latest commit to master?

I'm concerned that on the NuGet Gallery page it states Last updated 9 months ago

nblog commented 8 months ago

It comes from https://github.com/Microsoft/libyara.NET and it doesn't seem that Microsoft has updated it, maybe I'm trusting Microsoft too much😂, but to solve the runtime library conflict problem, I could modify it to reference libyara in source form, depending on which way you want to accept it?

kevoreilly commented 8 months ago

I'm not sure I follow - what runtime library conflict?

nblog commented 8 months ago

The compiled lib\libyara64.lib is bound by the C run-time library (CRT) and (/MD or /MDd) or (/MT or /MTd), which prevents arbitrary switching.

kevoreilly commented 8 months ago

Arbitrary switching?! What is that and why would the project benefit?

If it is intended for convenience to switch to an unsupported compiler, then unfortunately it's not an issue which needs fixing. The project focuses strongly on detonation quality which is demonstrably weakened by other compilers e.g. https://github.com/kevoreilly/capemon/issues/61

nblog commented 7 months ago

This is indeed a problem, we can wait for the problem to be solved before tweaking it, leaving it in the open for now might help with issues like #71 .

kevoreilly commented 7 months ago

There exists a problem with using VS2022, hence why this compiler is not supported. However this is not a capemon issue, so it's not an issue for this project.

The important point here is detonation quality is the only criterion for a valid issue, and there are currenrly no plans for VS2022 ever being supported.