Bazel was the build system used by VirusTotal. Now that VirusTotal has moved to YARA-X, maintaining the Bazel infrastructure working is painful, specially with the backward incompatible changes introduced in recent versions of Bazel.
* Import authenticode-parser into Yara. Rewrite PE signature processing using the authenticode-parser. Update bazel OpenSSL dependency to 1.1.1 from 1.1.0
* Forgot to include structs.c
* Add Avast to authors and myself to contributors
* Set forgotten algorithm_oid
* Fix incorrect indentation
* Fix race condition when initializing openssl objects
* Don't malloc ByteArray with length 0
* Auth. parser update - bug fixes, openssl3.0 support
* Update authenticode parser
Co-authored-by: Victor M. Alvarez <[email protected]>
The x86 platform is very forgiving when you access a 16-bits variable stored at a memory address that is not aligned to a 2-bytes boundary, or a 32-bits variable that is not aligned to 4-bytes boundary, and so on. Other platforms, like ARM or Sparc are not that flexible, and accessing a value by dereferencing a pointer that is not aligned to the size of the value causes a processor fault.
This fixes multiple issues caused by pointers that are not aligned to the size of the value.
Fixes: #1700
If a user specifies --enable-dotnet the build system will (currently) disable
the dotnet module, which is most certainly not what they want. This is likely to
cause unexpected issues for build systems (like brew, other third party
ports/package systems, and internal builds at $job) which have specified
--enable-dotnet automatically for a while now.
This diff fixes it by making --enable-dotnet print a warning message that this
option is no longer required, but it will still build the module.
The default behavior of building the module if neither --enable-dotnet or
--disable-dotnet is set is still maintained, along with honoring
--disable-dotnet.
Building with --enable-dotnet prints a warning and still builds the module:
```
wxs@wxs-mbp yara % ./configure --enable-dotnet > /dev/null
configure: WARNING:
*****************************************************************
The dotnet module is enabled by default now. No need to specify
--enable-dotnet. To disable this module please use
--disable-dotnet.
*****************************************************************
wxs@wxs-mbp yara % make clean >/dev/null
wxs@wxs-mbp yara % make | grep dotnet
CC modules/dotnet/dotnet.lo
wxs@wxs-mbp yara %
```
Building with --disable-dotnet does not build the module:
```
wxs@wxs-mbp yara % ./configure --disable-dotnet > /dev/null
wxs@wxs-mbp yara % make clean >/dev/null
wxs@wxs-mbp yara % make | grep dotnet
wxs@wxs-mbp yara %
```
And finally, building with neither option specified builds it by default:
```
wxs@wxs-mbp yara % ./configure > /dev/null
wxs@wxs-mbp yara % make clean >/dev/null
wxs@wxs-mbp yara % make | grep dotnet
CC modules/dotnet/dotnet.lo
wxs@wxs-mbp yara %
```
Add a --with-debug-verbose option to the configure script which takes a number
greater than 0 as an argument. This gives us the flexibility to make verbosity
of this useful debugging information greater than it's current maximum (2)
without needing to modify the configure script.
Currently the maximum is 2, which gets you a lot of useful runtime debugging
information. A value of 1 is only used in tests. It may be worth it to consider
reworking this system so the numbers describe how much information you want.
For example, 1 could just be function entry and exit, 2 could add arguments to
it. I'll leave changing that up to a future diff if it is desired.
While here, fix a warning in the scanner from using an incorrect format string:
scan.c:644:7: warning: format specifies type 'long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
match_offset,
^~~~~~~~~~~~~
./include/yara/globals.h:100:29: note: expanded from macro 'YR_DEBUG_FPRINTF'
fprintf(STREAM, FORMAT, __VA_ARGS__); \
~~~~~~ ^~~~~~~~~~~
1 warning generated.
Victor M. Alvarez