Added warning on unknown escape sequences #1880
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Whenever user makes a mistake in escape sequence it is being silently ignored.
For example if user writes
C:\Users\\[^\\]+\\test.txt
instead of
C:\\Users\\[^\\]+\\test.txt
YARA takes
\U
as an escape sequence and ignores it as there is not a rule to match (U is returned), therefore this would match strings starting withC:Users
instead ofC:\Users
.Another case where this problem would rise is even within YARA tests. There is
\0x5A
value being escaped in range test. YARA does not support leading 0 in escaping, therefore it escapes only\0
, returns0
and continues with the rest being treated as a normal string. We would then get range65-93
(65 is a decimal value for ASCII A and 93 for\x5D
) instead of desired range91-93
in decimal values. The test is not failing as the tested value is within both ranges but if you try something that should fail as a\x4F
it still passes.