Previously, gcc (Debian 10.2.1-6) 10.2.1 20210110 gave the following
error message:
/usr/bin/ld: tests/util.o:(.data+0x0): multiple definition of `matches_blob_uses_default_iterator'; tests/test-arena.o:(.bss+0x0): first defined here
* Fix issue #1443.
As pointed out in the bug report the way of aligning the win_cert pointer to the next 8-bytes boundary is not correct. If the previous certificates ends at 0x1234000A, the next one should start at 0x12340010, not at 0x1234000c which is not aligned to 8 bytes.
This tries to avoid nasty bugs caused by a different bool sizes. For example, the library is built with HAVE_STDBOOL_H defined, and some binary linking to the library is built without HAVE_STDBOOL_H, the library thinks that sizeof(bool) == sizeof(_Bool) == 1, while the binary thinks that sizeof(bool) == sizeof(int) == 4. This discrepancy in sizes can lead to data corruption.
With this change the yr_scanner_scan_mem_blocks function can return ERROR_BLOCK_NOT_READY when the YR_MEMORY_BLOCK_ITERATOR that provides memory blocks to the function is not ready to return the next block. After this error the caller can retry the call to yr_scanner_scan_mem_blocks multiple times until the function succeeds or fails with some other error code.
Co-authored-by: Simon Hardy-Francis <[email protected]>
The strncpy function was being invoked with a source buffer that was shorter than MAX_TYPELIB_SIZE and the string was not null-terminated, which means that strncpy read past the end of the buffer. Now the limit pass to strncpy is the length of the string as indicated in the byte before the string itself. This length, being a byte, is equal to or less than MAX_TYPELIB_SIZE whose value is 255.
* tests: Disable process scanning test on Windows
There's no sys/wait.h and no fork, so let's just #ifdef it out.
* tests: Open sample files in binary mode
Relevant on Windows.
When we hit the maximum match limit on a string we currently abort all scanning,
which can be problematic since it isn't a good reason to stop all scanning, and
is better off as a warning to the user.
This commit makes it so that when the string match limit is hit a warning is
printed and scanning will continue. The warning message indicates that the
results may be invalid. It is hard to know for certain if they are invalid
because it depends entirely upon the condition. If you use the # or @ operator
then your condition _MAY_ be invalid since the total number of matches and
locations is not known anymore. Just checking that the string exists won't be an
invalid state since we have confirmed the existence of _AT LEAST_ the maximum
number of occurrences, which clearly satisfies the existence of a single
instance of your string.
I decided to implement this as a callback so the user of libyara has some choice
on the default behavior. If they want to consider this a "stop all scanning"
error they are free to return CALLBACK_ERROR in their callback.
* Implement pe.entry_point_raw.
Add pe.entry_point_raw which is the raw value of the entry point field from the
optional header. This value is NOT converted to a file offset or a virtual
address, and is just the raw bytes taken straight from the header.
This allows you to use the entry point as it is specified in the file without
having to jump through hoops to parse it by hand in your condition.
* Specify the version in which entry_point_raw was added.
Co-authored-by: Victor M. Alvarez <[email protected]>
Add the following helper methods to the dex module:
dex.has_method("foo") - Returns true if any method has the literal name "foo".
dex.has_method(/foo/") - Returns true if any method name matches the regex.
dex.has_class("foo") - Returns true if any class has the literal name "foo".
dex.has_class(/foo/) - Returns true if any class name matches the regex.
dex.has_method("foo", "bar") - Returns true if any class has the literal name
"foo" and any method has the literal name "bar".
dex.has_method(/foo/, /bar/) - Returns true if any class name matches the regex
/foo/ and any method name matches the regex /bar/.
* Review all calls to YR_DEBUG_FPRINTF and make the following changes:
* Use PRIx64 and PRIi64 for printing 64-bits values, which is more portable.
* Use %zu for printing size_t types.
* Remove the empty {} at the end of printed messages, as they don't provide that much information and clutter the format string
* Don't use ' in format strings for thousand separators as this is not very portable (https://stackoverflow.com/questions/10234766/warning-using-icc-and-printf-with-thousands-grouping-format-apostrophe)
* Re-introduce the curly braces in YR_DEBUG_FPRINTF messages.
This removes 3 unused bytes at the end of each SIZED_STRING. Those 3 bytes are not initialized by alloc_sized_string and cause MemorySanitizer to fail with use-of-uninitialized-value.
The current Mach-O parsing code attempts to call macho_rva_to_offset
while parsing load commands and before it has set number_of_segments.
Since macho_rva_to_offset uses number_of_segments this can result
in it using a number_of_segments that is uninitialized and is just a random
large number. In turn yara runs a really long time.
This adds a test binary based on this post
https://codegolf.stackexchange.com/questions/102471/smallest-possible-runnable-mach-o-executable/154685#154685
It has two load commands. The first is a LC_UNIXTHREAD command and
the second is a LC_SEGMENT command. It's a valid 386 Mach-O binary.
It reproduces this error.
UPX packed files will cause export parsing to stop parsing because the function
address is not a valid RVA, and I was refusing to parse that export in that
case.
This is a regression from how we used to do parsing (we were never checking the
export RVA so it was never considered in prior releases). This is causing rules
which used to work to no longer work on packed samples. Specifically, checking
for a DLL which is UPX packed using pe.exports("foo") is likely to not work in
4.0.0 when it used to work in 3.11.0.
Apologies for missing this, but to make sure it doesn't happen again in the
future I've added a test case for this (just packed an existing DLL that is in
the repo).
Add test for invalid use of base64 and fullword together
Skip second base64 encoding of single ascii byte
Add test for correct base64 encoding of single ascii byte
This changes the way in which comparison operators, and also the "contains" and "matches" operators handle undefined operands. Before this change the result of such operations was undefined, after this change the result is false.
Hilko Bengen